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1.  INTRODUCTION 


The  primary  purpose  of  this  volume  is  to  present  a  series  of  key 
support  issues  that  face  today's  ECS  support  managers.  This  section 
will  present  some  of  the  background  that  has  led  to  today's  ECS  support 
posture,  a  brief  summary  of  the  key  findings  of  the  analysis  of  AFLC's 
current  support  posture,  and  an  introduction  to  the  key  support  issues  to 
be  discussed  in  this  volume. 

Finally,  Appendix  A  of  this  volume  presents  a  series  of  recommenda¬ 
tions  that  would  improve  AFLC's  current  support  posture,  if  implemented. 
Table  A-  1  includes  recommendations  that  can  be  implemented  via  manage¬ 
ment  directives  or  direct  management  action.  Table  A- 2  includes  recom¬ 
mendations  that  most  likely  will  require  some  form  of  programmatic 
action  to  implement. 

1.  1  BACKGROUND 

Historically,  the  role  of  AFLC  has  been  to  provide  support  to  TAC, 
SAC,  and  the  other  operational  commands  by  ensuring  that  all  Air  Force 
systems  were  operational  through  buying,  supplying,  transporting,  and 
maintaining  systems  and  systems  components.  Accordingly,  repair  and 
modification  facilities  were  conceived  and  established,  large  quantities 
of  spares  were  projected  and  procured,  and  a  logistics  system  evolved  to 
facilitate  distribution  of  needed  support  to  worldwide  locations. 

The  requirements  of  supporting  Embedded  Computer  Systems  (ECS) 
have  significantly  altered  logistic  support  requirements.  The  responsi¬ 
bility  for  making  modifications  to  systems  (especially  those  with  embedded 
computer  systems  such  as  the  F- 1 1 1,  F-4,  and  F-  16)  has  been,  or  in  the 
future  will  be,  transitioned  to  the  Logistics  Command  from  AFSC.  The 
acquisition  of  support  systems  for  embedded  computer  systems,  including 
Integration  Support  Facilities  (ISF's)  and  the  engineering  that  is  prerequi¬ 
site  to  deciding  technical  issues  about  embedded  computer  software  modi¬ 
fications  or  support  systems,  constitutes  an  engineering  intensive  program 
and  has  the  characteristics  of  a  high  technology  modification  program. 


Within  the  last  ten  years  or  so,  the  requirements  for  supporting 
systems  which  contain  embedded  computer  systems  have  emerged.  The 
fact  that  computers  are  embedded  indicates  a  more  versatile  yet  complex 
system.  In  other  words,  avionics  devices  have  migrated  from  simple, 
independent  components  to  complex,  interdependent  systems  whose  modi¬ 
fication  requires  a  much  higher  degree  of  sophisticated  system  knowledge 
and  analysis.  The  computer  software  of  newer  systems  is  interrelated 
with  the  system  design,  and  system  capability  can  often  be  changed  by 
altering  only  the  software.  Although  software  controlled  systems  offer 
added  flexibility,  the  support  requirements  now  are  directly  coupled  to 
the  operational  success  of  the  system.  Where  older  systems  lent  them¬ 
selves  to  separation  of  development  and  support,  the  newer  systems  are 
not  distinguishable  between  the  development  and  support  aspects.  Thus 
it  follows  that  for  embedded  computer  systems  there  is  an  overlap  in  the 
traditional  AFSC  and  AFLC  responsibilities  and  it  is  no  longer  obvious 
where  the  responsibilities  for  system  acquisition  and  major  modifications 
stop  and  the  responsibilities  for  logistics  support  begin.  This  overlap  has 
caused  AFLC  to  enter  the  realm  of  engineering  intensive  support.  The 
involvement  of  AFLC  in  this  highly  technical  arena  has  evolved  so  grad¬ 
ually  over  the  past  several  years  that  its  impact  was  never  seen  as  a 
newly  identified  problem  which  would  have  to  be  mastered.  In  essence, 
the  AFLC  migration  into  engineering  intensive  activities  has  been  gradual, 
but  is  now  very  pronounced  and  an  important  part  of  AFLC  activities. 
Because  Air  Force  weapon  system  capability  and  military  readiness  are 
directly  coupled  to  software  support,  the  necessity  for  establishing  an 
effective  support  posture  is  directly  mission  related  and  of  grave 
importance. 

The  changing  role  in  AFLC  is  symptomatic  of  changes  in  technology. 
Technological  advances  have  occurred  in  virtually  all  aspects  of  weapon 
system  function,  thus,  the  weapon  system  capabilities  have  improved  as 
the  systems  have  become  more  sophisticated  and  complex.  The  trend 
toward  more  sophisticated  systems  encompassing  embedded  computer 
systems  as  an  essential  part  of  system  structure  is  expected  to  accelerate 
in  the  future.  Very  High  Speed  Integrated  Circuits  (VHSIC),  fiber  optics, 
microprocessors,  distributed  processing  using  embedded  computers,  and 


1-2 


computer  memory  developments  are  but  a  few  of  the  rapidly  changing 
technologies  that  will  mandate  changes  in  AFLC  policy  and  management 
if  maintenance  and  support  are  to  keep  pace  with  the  Air  Force's  needs. 
Software  and/or  firmware  is  playing  an  active  and  expanding  role  in  each 
of  these  technologies  so  the  trend  will  be  toward  more  software  as  an 
inherent  part  of  future  weapon  systems.  Costs  of  system  acquisition  have 
migrated  from  being  hardware  driven  to  a  mixture  of  hardware  and  soft¬ 
ware,  with  the  future  predicted  to  be  heavily  software  driven.  Translated, 
software  costs  affect  labor  costs  rather  than  material  costs. 

Management  for  both  development  and  support  of  embedded  computer 
systems  is  engineering  intensive  because  the  tasks  themselves  are  more 
technical  and  complex.  Interrelated  systems  using  software  require  more 
sophisticated  engineering  design  or  else  the  entire  system  capability  is 
jeopardized.  Since  both  the  management  and  technical  trends  are  more 
toward  engineering  tasks,  it  appears  that  some  realignment  of  AFLC 
policy  and  procedures  is  required.  For  example,  engineering  support 
has  always  been  a  portion  of  total  logistics  support;  but,  as  the  engineer¬ 
ing  support  occupies  a  larger  portion  of  the  total  logistics  support,  the 
question  arises  as  to  whether  the  traditional  AFLC  priorities  and  pro¬ 
cedures  can  be  efficiently  applied.  The  trend  also  is  toward  more  and 
more  expertise  to  analyze  technical  deficiencies  and/or  anomalies  of  the 
systems.  This  trend  requires  both  hardware  and  software  knowledge  that 
applies  to  the  weapons  or  avionics  systems  as  well  as  the  associated  sup¬ 
port  systems.  Similar  trends  are  occurring  within  civilian  industrial 
realms  and,  consequently,  the  overall  competition  for  engineering  talent 
is  increased. 

Typically,  the  problems  associated  with  supporting  embedded  com¬ 
puter  systems  have  been  categorized  into  two  types:  technology  related 
and  management  related.  Closer  examination  indicates  the  management 
related  problems  are  only  symptomatic  of  the  technology  related  problems, 
and  because  the  AFLC  role  is  changing  into  more  technological  involve¬ 
ment,  the  reaction  to  this  involvement  causes  management  perturbation. 
Realization  that  problems  exist  does  not  indicate  that  AFLC  management 
personnel  are  negligent  or  are  not  doing  their  job,  but  rather  the  existent 
management  practices  do  not  efficiently  apply  to  the  changed  AFLC  role. 
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Prior  to  addressing  some  of  the  existent  problems /issues  within 
AFLC  which  are  a  by-product  of  the  changing  role  of  AFLC,  it  is  appro¬ 
priate  to  note  that  there  are  areas  where  much  has  been  accomplished. 

In  other  words,  the  AFLC  response  to  the  changing  role  is  not  one  of  fail¬ 
ure,  but  one  of  success  with  a  concern  to  be  even  more  successful. 
Although  self-criticism  is  offered  by  internal  AFLC  elements  about  lack 
of  accomplishment  in  adjusting  to  the  new  role,  the  fact  is  that  many  of 
the  currently  identified  problems /issues  are  currently  being  worked  with 
whole  or  partial  solutions  likely  within  the  near  term.  During  this  evo¬ 
lutionary  period  AFLC  has 

•  Provided  effective  support  for  those  ECS's  for  which 
organic  software  change  responsibility  was  assigned  to 
AFLC  (i.e.,  F-lll  and  ALR-46). 

•  Developed  an  effective  organic  engineering  capability  which 
uses  both  organic  and  contractor  resources. 

•  Provided  implementation  directives  supporting  AFR  800-  14 
such  as  Supplement  1  to  AFR  800-  14  and  AFLCR  800-21. 

•  Developed  AFLCR  400-xx,  Generic  Logistics  Decision 
Tree  (GLDT). 

•  Demonstrated  the  capability  to  organically  develop/integrate 
sophisticated  ECS  support  facilities  such  as  the  F-15  AISF 
and  the  EWAISF. 

•  Been  in  the  forefront  in  developing  the  support  concept  for 
organically  supported  ECS's  as  evidenced  by  the  lead  role 
in  the  EW  integrated  reprogramming  concept. 

•  Made  major  strides  in  organizational  alignment  at  the  ALC, 
ALD,  and  Headquarters  levels  to  effect  a  better  ECS  sup¬ 
port  posture. 

•  Shown  an  ability  to  attract  required  engineering  talent. 

This  is  an  on-going  effort  and  many  of  the  AFLC's  areas  of  progress 
are  noteworthy.  Although  this  list  of  accomplishments  represents  only  a 
portion  of  the  overall  success  of  AFLC  in  reacting  to  its  changed  role,  the 
list  is  indicative  that  AFLC  management  is  aware  of  the  significance  and 
impact  of  ECS  software  support.  It  is  encouraging  to  note  that  these 
accomplishments  were  done  concurrently  with  completing  one  of  the  most 
successful  periods  in  history  of  providing  traditional  AFLC  support  to  its 
users.  It  should  be  emphasized,  however,  that  the  complexity  and 
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sophistication  of  ECS's  have  increased  in  recent  years  and  currently 
several  problems /issues  prevail  in  providing  adequate  software  support. 
The  need  for  further  improvement  in  technical  and  management  efficiency 
to  meet  the  demands  of  future  ECS  support  is  high. 

It  is  in  the  light  of  improving  and  enhancing  ECS  support  that  AFLC 
exhibited  the  initiative  to  solicit  external,  unbiased  assistance  in  examin¬ 
ing  current  ECS  support  posture  and  forecasting  future  ECS  support  objec¬ 
tives.  Thus,  the  requirement  for  an  independent  study  effort  was  identi¬ 
fied  and  TRW  was  contracted  to  critically  examine  the  current  AFLC  ECS 
software  support  posture,  to  forecast  future  ECS  support  objectives,  and 
to  lay  out  a  plan  which  AFLC  can  implement  to  get  from  its  current  sup¬ 
port  posture  to  the  projected  future  support  posture.  This  role  differs 
from  typical  internal  self-inspection  roles  in  that  the  self- inspections 
normally  examine  the  ALC's  for  adherence  to  procedures  and  regulations 
rather  than  assessing  the  applicability  and  efficiency  of  implemented  con¬ 
cepts  and  regulations  in  accomplishing  the  software  support  of  ECS. 

1.  2  REQUIREMENTS  BASELINE  SUMMARIES 

TRW's  analysis  of  AFLC's  current  ECS  support  posture  was  sep¬ 
arated  into  five  subtasks.  Each  subtask  specifically  examined  one  of  the 
following  ECS  categories. 

•  Aircrew  Training  Devices  (ATD) 

•  Automatic  Test  Equipment  (ATE) 

•  Communications-Electronics  (C-E) 

•  Electronic  Warfare  (EW) 

•  Operational  Flight  Programs  (OFP) 

The  following  paragraphs  present  a  brief  summary  of  the  major  findings 
of  the  analysis  for  each  category. 

1.  2.  1  Aircrew  Training  Devices 

Each  Aircrew  Training  Device  (ATD)  is  designed  to  model  all  or 
part  of  a  primary  weapon  system.  Changes  in  the  primary  system  which 
affect  its  aircrew  interface  may  need  to  be  modeled  concurrently  in  the 
ATD.  Aircrew  training  devices  are  supported  at  training  sites  under  the 
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Development  Engineering  Prototype  Site  (DEPS)  concept.  A  DEPS  is  a 
site  where  an  ATD  is  installed  and  used  for  both  training  and  support 
activities.  The  DEPS  concept  enables  some  organic  accomplishment  of 
ATD  modifications,  but  introduces  a  dual  update  path  (one  by  the  ATD  user 
and  one  by  the  ATD  supporter)  which  is  accompanied  by  configuration  con¬ 
trol  and  implementation  problems.  ATD  support  posture  is  adequate  to 
allow  operation  of  the  trainers,  but  much  of  the  responsibility  for  pro¬ 
cedures  to  update  or  change  the  ATD's  is  vaguely  defined.  Specific  sup¬ 
port  problems  include:  (1)  trainers  are  not  modified  concurrently  with 
aircraft  modification,  thus  training  experience  gained  on  the  ATD's  can 
be  obsolete  for  its  real  system  capability,  (2)  the  two  paths  which  exist 
for  creating  changes  have  resulted  in  poor  basehne  control,  (3)  no  organic 
capability  to  handle  software  media  nor  a  s  vftware  repository  are  estab¬ 
lished,  (4)  the  DEPS  and  ALC  communications  need  improvement,  and 
(5)  modifications  frequently  require  the  use  of  i*ole  source  contracts  to 
the  system  developer  due  to  lack  of  a  bat  ::  u  e.  All  of  these  problems 
are  addressed  in  greater  detail  in  tht  ATD  volume  of  this  study. 

1.  2.  2  Automatic  Test  Equipment 

The  concept  for  supporting  Automatic  Test  Equipment  (ATE)  and 
using  ATE  for  testing  of  weapon  systems  and  components  involves: 

(1)  the  Software  Support  Center  for  programming  changes,  (2)  the  Engi¬ 
neering  Division  for  analyzing  deficiencies  and  designing  corrective 
changes,  (3)  the  Maintenance  Directorate  for  operating  ATE,  (4)  ADPE 
support  on  an  "as  needed"  basis  from  the  Comptroller  Directorate,  and 
(5)  an  assortment  of  procedures  and  organizational  relationships.  Auto¬ 
matic  testing  is  plagued  with  complexity,  proliferation,  and  a  general 
lack  of  understanding.  The  AFLC  support  for  ATE  is  aggravated  by  poor 
quality  deliveries  of  ATE  software  which  means  the  software  development 
must  be  completed  within  AFLC.  Specific  support  problems  are:  (1)  inade¬ 
quate  development  of  test  program  set,  (2)  poor  UUT  test  program  quality, 
(3)  inadequate  consideration  of  design  for  testability,  (4)  undefined  or 
conflicting  responsibilities,  (5)  poor  configuration  management,  (6)  logis¬ 
tics  management  discipline  applied  to  engineering  problems,  (7)  lack  of 
documentation,  and  (8)  poor  management  knowledge  of  ATE  status.  Most 
problems  extend  from  a  lack  of  planning  to  define  the  ATE  required  and  a 


lack  of  completing  the  ATE  software  to  an  acceptable  and/or  useable 
state.  All  of  these  problems  are  addressed  in  greater  detail  in  the  ATE 
volume  of  this  study. 

1.  2,  3  Communications  - Electronics 

Most  of  the  systems  allocated  to  Communications- Electronics  (C-E) 
are  large,  few- of- a- kind  systems.  Further,  the  using  command  is  some¬ 
times  either  totally  or  partially  responsible  for  supporting  the  ECS  soft¬ 
ware.  Thus,  the  total  support  from  AFLC  varies  from  system  to  system. 
Much  of  the  support  is  contracted  to  the  prime  contractor  or  his  alternate, 
especially  for  one-of-a-kind  systems.  Problems  are  prevalent  within  the 
C-E  category  because:  (1)  mixed  user /AFLC  support  responsibilities 
dilute  configuration  management,  (2)  planning  and  procedural  documents 
are  neither  adequate  nor  timely,  (3)  technical  requirements  are  straining 
traditional  management  and  training  structures,  (4)  new  combat  support 
roles  require  increased  resource  planning  and  implementation,  and  (5) 
C-E  support  responsibilities  are  distributed  among  the  ALC's.  All  of 
these  problems  are  addressed  in  greater  detail  in  the  C-E  volume  of  this 
study. 

1.  2.  4  Electronic  Warfare 

The  concept  for  supporting  both  ground-based  and  airborne  Elec¬ 
tronic  Warfare  (EW)  systems  is  very  similar  because  it  uses  a  support 
station  for  each  system  but  ties  the  systems  together  with  some  central¬ 
ized  support.  EW  systems  are  dynamic  systems  in  that  they  are  altered 
in  response  to  changes  in  enemy  threats  on  a  near-continuous  basis.  This 
alteration  necessitates  a  rapid  reprogramming  capability  and  a  need  to 
operate  updated  systems  as  soon  as  possible.  Continued  development  of 
many  systems  has  caused  poor  documentation  or  ill-defined  baselines, 
thus  configuration  control  is  weakened.  Specific  areas  of  concern  in  EW 
are:  (1)  need  for  additional  standardization  from  system  to  system, 

(2)  incomplete  software  and  baseline  documentation,  (3)  lack  of  necessary 
software  tools,  (4)  insufficient  personnel  with  system  expertise,  (5)  need 
for  improved  communication  and  analysis  capability  of  intelligence  data, 
and  (6)  more  responsiveness  to  software  changes.  All  of  these  problems 
are  addressed  in  greater  detail  in  the  EW  volume  of  this  study. 
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1.  2.  5  Operational  Flight  Program 

Operational  Flight  Programs  (OFP's)  represent  the  system  capa¬ 
bility  of  avionics  in  that  the  application  of  the  system  is  described  by  the 
software.  The  OFP's  are  integral  to  the  intent  of  the  system  and  all 
interfaces  with  the  system  have  an  effect  upon  the  results  obtained  by 
using  the  OFP's.  In  its  broadest  context,  OFP  can  include  EW  software, 
C-E  software,  ATD  software,  and  even  a  portion  of  ATE  software.  The 
distinction  is  made  for  OFP  because  of  its  direct  relationship  to  weapon 
systems  such  as  aircraft  or  missiles.  The  concept  for  supporting  OFP's 
is  an  Avionics  Integration  Support  Facility  (AISF).  Establishment  of  an 
AISF  enables  all  interfaces  with  an  avionics  system  or  systems  to  be  sim¬ 
ulated  or  implemented  so  that  the  avionics  OFP's  can  be  exercised.  Addi¬ 
tionally,  AISF's  facilitate  updates  and/or  changes  to  the  OFP's  plus  some 
validation  and  verification  checks  of  the  revised  OFP.  Problems  asso¬ 
ciated  with  AISF's  or  support  of  OFP's  stem  primarily  from  the  complex¬ 
ity  of  the  AISF's  themselves.  It  is  very  difficult  to  initially  conceive  and 
implement  a  complete  AISF  at  the  outset  of  its  establishment.  Thus, 
AISF's  are  evolutionary.  This  is  neither  to  say  that  the  approach  is  wrong 
nor  the  overall  AISF  design  is  inadequate,  for  this  is  not  the  case  at  all. 
AISF's  must  test  to  a  specific  set  of  parameters  in  a  specific  scenario 
before  meaningful  technical  analysis  is  possible.  It  is  this  level  of  speci¬ 
ficity  that  is  evolutionary.  Specific  problem  areas  noted  in  OFP  support 
are:  (1)  the  AISF  concept  is  not  uniformly  implemented  although  most 
AISF's  are  patterned  after  the  F-lll  AISF  established  at  Sacramento, 

(2)  terminology  and  procedures  are  not  equally  implemented,  (3)  docu¬ 
mentation  is  incomplete,  causing  configuration  management  weakness, 

(4)  the  F-4  AISF  is  not  a  full  support  capability,  (5)  support  requirements 
are  not  firm,  and  (6)  all  or  part  of  the  facilities  used  during  development 
are  "handed  down"  to  AFLC  to  use  as  the  support  equipment  for  avionics 
systems.  All  of  these  problems  are  addressed  in  greater  detail  in  the 
OFP  volume  of  this  study. 

1.  3  ECS  SUPPORT  ISSUES 

To  assess  the  major  issues  confronting  the  ECS  manager  today, 

TRW  convened  a  working  group  of  senior  engineering  personnel  with 
expertise  in  the  support  of  embedded  computers  owned  by  both  government 
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and  industry.  The  purpose  of  this  group  was  to  ascertain  the  major  issues 
involved  in  ECS  support  from  a  logistics  perspective.  The  method  of 
selecting  the  most  prominent  issues /drivers  was  the  identification  of  a 
large  group  of  alleged  management  problem  areas  that  had  been: 

•  Stated  in  various  Air  Force  documents  reviewed  by  TRW 

•  Related  to  TRW  personnel  by  Air  Force  customers 

•  Observed  by  TRW  personnel  in  the  conduct  of  contractual 
tasks  involving  ECS 

The  list  assimilated  during  the  initial  exercise  consisted  of  approximately 
100  purported  issues.  This  list  was  reduced  by  eliminating  items  that 
were  essentially  technological  issues  which  were  then  referred  to  another 
working  group  tasked  to  make  a  technology  assessment.  Another  method 
of  reducing  the  number  of  issues  was  the  elimination  of  redundant  issues 
(perceived  and  stated  in  different  ways)  and  the  consolidation  of  closely 
related  issues.  Issues  for  consideration  by  the  working  group  did  not 
include  issues  which  were  unique  to  an  ECS  category  since  these  would  be 
identified  in  the  baselining  activities.  Items  on  the  resulting  list  were 
then  evaluated  as  to  their: 

•  Definability 

•  Reported  impact  to  the  AFLC  support  posture 

•  Practicality  of  defining  and  implementing  resolutions  to 
the  alleged  issue 

Each  issue  was  given  a  numerical  order  or  merit  rating  on  each  of  the 
preceding  three  factors.  From  the  preceding  evaluation,  17  primary 
issues  were  identified  for  further  study.  The  group  collectively  identi¬ 
fied  a  preliminary  list  of  key  elements  to  be  considered  in  the  evaluation 
of  each  issue.  The  key  elements  were  initially  developed  as  areas  of 
consideration  as  a  means  of  providing  a  stimulus  to  investigate  particu¬ 
lar  facets  of  an  issue.  These  elements  were  further  refined  by  the  working 
group  as  the  pertinent  points  of  the  issue  became  more  visible.  Due  to 
the  subjective  nature  of  each  issue  and  the  fact  that  many  of  these  same 
issues  had  been  or  were  being  considered  by  AFLC,  AFALD,  and  ALC 
management,  a  white  paper  approach  was  taken  to  investigate  this  initial 
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list  of  issues /drivers.  Each  issue  was  assigned  for  investigation  to  a 
member  of  the  working  group  possessing  expertise  in  that  particular  area. 
The  result  of  this  investigation  was  an  internal  white  paper  which  was 
then  evaluated  by  all  other  members  of  the  working  group  individually. 

These  white  papers  were  then  iterated  and  finally  prepared  for  inclusion 
in  this  volume.  During  the  evaluation  leading  to  the  issue  white  papers, 
the  primary  evaluation  methods  were: 

•  Investigation  of  existing  Air  Force  data  such  as  studies, 
briefings,  whitepapers,  etc.,  related  to  the  subject. 

•  Investigation  of  directive  guidance  pertaining  to  the  par¬ 
ticular  subject. 

•  Interaction  with  Air  Force  ECS  engineers  and  managers 
concerning  their  views  on  the  particular  subject. 

•  Solicitation  of  information  on  the  subject  from  other  TRW 
personnel. 

During  the  integration  of  the  white  papers  into  this  report,  a  further 
consolidation  was  made  leaving  the  following  nine  subjects  as  the  manage¬ 
ment  issues  with  the  most  impact  on  AFLC  support  posture: 

•  ECS  readiness  support  concept 

•  Personnel  and  training 

•  Microprocessors  and  firmware  support 

•  AFR-800  versus  AFR-300  series  acquisition/support 

•  Configuration  management 

•  Facility  planning /funding /maintenance 

•  Funding 

•  Product/data  quality  at  transition 

•  Management  structure 

Summarized  in  this  volume,  the  TRW  observations  of  existent  needs, 
issues,  and  problems  are  not  offered  in  a  negative  context;  but  simply  to 
identify  the  current  AFLC  ECS  support  situation  from  a  critical  perspective. 
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In  other  words,  highlight  areas  of  inefficiency,  inaccuracy,  or  less  than 
adequate  support.  Because  no  single  system  of  management  or  support 
is  a  perfect  system,  imperfections  can  be  discovered  by  a  knowledgeable 
investigation  and  analysis.  Discernment  of  a  problem  or  issue  is  the 
first  step  in  deriving  and  implementing  a  solution.  It  is  in  this  context 
that  the  following  is  sues /problems  are  discussed  in  Sections  2  through 
10  of  this  volume. 
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2.  ECS  READINESS  SUPPORT  CONCEPT 


2.  1  BACKGROUND 

During  World  War  II  the  Soviets  became  convinced  that  in  order  to 
win  any  future  conflict,  it  would  be  necessary  to  control  the  electromag¬ 
netic  environment  surrounding  the  battlefield.  As  a  result,  beginning  in 
early  1942  the  Soviets  embarked  upon  a  combined  arms  concept  for  the 
employment  of  electronic  warfare  assets.  From  that  time  forward  they 
have  developed  the  concept  and  fielded  the  equipment  necessary  to  com¬ 
bine  fire  power  with  classic  electronic  jamming  on  the  battlefield.  This 
concept  is  referred  to  as  Radio  Electronic  Combat  (REC)  and  has  been  a 
subject  of  great  interest  to  both  the  Air  Force  and  Department  of  Defense 
(DOD)  over  the  last  few  years. 

The  Soviet  REC  concept  targets  NATO  and  U.  S.  Command  and  Con¬ 
trol  elements  to  include  the: 

•  Controlling  agency 

•  Communication  links 

•  Controlled  entities  on  board  avionics  (i.  e.  ,  the  F-15/ 

F-16  fire  control  radars,  IFF,  navigation  system  and 
communication  links;  under  this  concept./  fire  control 
radars  are  a  high  priority  target 

Using  this  targeting  philosophy,  the  Soviets  invested  large  resources 
in  obtaining  the  lethal  and  non-lethal  assets  along  with  the  location  equip¬ 
ment  required  to  degrade  or  destroy  more  than  half  of  NATO/U.  S.  capa¬ 
bilities  in  this  area.  Of  this  goal,  the  Soviets  have  divided  the  responsi¬ 
bilities  between  lethal  (firepower)  and  non-lethal  (jamming)  missions. 

General  J.  W.  Pauly,  Commander  of  Allied  Air  Forces  Command 
Europe  and  Commander  in  Chief  of  U.  S.  Air  Forces  in  Europe,  recently 
gave  a  speech  before  the  Air  Force  Association.  Quotations  from  the 
speech  indicate  just  how  seriously  senior  Air  Force  officials  view  this 
threat  to  the  operational  capabilities  of  our  tactical  forces.  General  Pauly 
stated, 

Since  last  October,  we  have  seen  evidence  that  they 
(the  Warsaw  Pact  countries)  are  introducing  new  elec¬ 
tronic  warfare  equipment  —  adding  to  the  overwhelming 


capability  already  possessed  by  the  Warsaw  Pact. 

Their  concept  of  what  they  call  "radio  electronic 
combat"  combines  electronic  warfare  and  recon¬ 
naissance  resources  with  firepower  to  limit,  delay, 
or  neutralize  our  use  of  command  and  control  sys¬ 
tems.  They  already  enjoy  an  overwhelming  advan¬ 
tage  in  the  number  of  airborne  stand-off  jamming 
platforms  and  ground-based  jammers.  In  the  latter 
case,  the  ratio  is  13  to  1  in  their  favor.  Is  anyone 
listening  ?t 

While  there  have  been  several  studies  and  estimates  made  on  U.  S. 
systems'  vulnerabilities  (Reference  2-1),  an  exact  assessment  of  Soviet 
capabilities  in  this  area  is  complicated  by  the  difficulty  in  "collecting" 
actual  jamming  emissions.  For  example,  unmanned  collectors  treat 
noise  jamming  as  "noise  interference"  and  actually  remove  the  signal 
from  the  collector's  "take".  Deception  jamming  is  even  more  illusive 
in  that,  in  order  to  collect  the  signal,  the  collector  must  first  stimulate 
the  jammer  and  then  remain  in  the  jammer's  field  of  view  throughout  the 
collection  effort.  Given  the  collection  restraints,  many  experts  in  this 
field  estimate  that  available  documentation  on  Soviet  EW  equipment  is 
many  years  behind  their  actual  capabilities. 

While  the  Soviets  have  been  actively  and  aggressively  pursuing  the 
objectives  of  the  REC  concept,  U.  S.  forces  and  most  allies  have  increased 
their  military  capability  depending  upon  the  use  of  the  electromagnetic 
spectrum.  Under  the  direction  of  Secretary  of  State  McNamara,  the 
Department  of  Defense  implemented  the  concept  of  "force  multiplier.  " 

In  almost  all  cases  the  success  of  a  "force  multiplie  "  weapon  system 
is  heavily  dependent  upon  successful  use  of  the  electromagnetic  spectrum; 
i.  e.  ,  AWACS,  command  and  control,  and  fire  control  systems  of  the  F-15/ 
F-16.  This  heavy  dependency  upon  the  use  of  the  electromagnetic  environ¬ 
ment  without  an  adequate  understanding  and  appreciation  for  the  Soviet 
REC  has  resulted  in  the  continued  development  and  fielding  of  systems 
which  are  susceptible  to  electronic  jamming  and  degradation. 

Not  only  does  the  REC  concept  advocate  active  interference  and 
degradation  of  U.  S.  electronic  equipment,  it  places  equal  emphasis  on 

^Additional  insight  into  specific  U.  S.  system  vulnerabilities  can  be  gleaned 
from  Reference  2-  1. 


protecting  Soviet  command  and  control  elements  from  U.  S.  jamming. 
Examples  of  the  implementation  of  this  aspect  of  REC  is  found  in  the 
ECCM  fixes,  procedures,  and  training  of  Soviet  radars  and  radar  oper¬ 
ators.  The  ECCM  fixes  include  parametric  agility,  low  radar  sidelobes, 
monopulse  processing,  wartime  mode  of  operation,  frequency  diversity, 
radar  and  communication  redundancy,  emission  security,  and  active 
training  in  an  ECCM  environment.  All  of  these  efforts  have  complicated 
the  task  of  the  U.  S.  ECM  designer  and  support  organizations.  Nowhere 
was  this  more  visually  illustrated  than  in  the  Southeast  Asia  (SEA)  con¬ 
flict  with  the  move- countermove  game  between  the  U.S.  ECM  designers 
and  support  organizations  versus  the  Soviet-built  SA-2  system.  Through¬ 
out  this  "move-countermove"  game  it  became  apparent  that  it  was  impos¬ 
sible  to  react,  within  the  time,  required  to  a  change  in  the  SA-2  using 
the  U.  S.  hardware  modification  approach.  As  a  result,  the  use  of 
"Embedded  Computers"  in  the  U.S.  EW  equipment,  and  their  ability  to 
be  changed  through  software,  became  an  accepted  Air  Force  solution  to 
a  dynamic  electromagnetic  threat  situation.  However,  ECS  and  their 
support  require  unique  support  concepts.  These  support  concepts  include 
availability  and  use  of  sensitive  intelligence  data,  unique  software  tools, 
and  new  management  initiatives.  The  following  paragraphs  will  amplify 
on  each  of  these  areas. 

2.2  INTELLIGENCE  SUPPORT 

The  use  of  embedded  computers  in  U.S.  avionics,  coupled  with  the 
dynamics  of  the  electromagnetic  battlefield  environment,  dictates  a  funda¬ 
mental  change  in  the  historical  AFLC  support  mission.  Nowhere  is  this 
more  evident  than  in  the  area  of  intelligence  support.  Figure  2-1  illus¬ 
trates  the  problems  from  an  airborne  electronic  warfare  view. 

This  figure  depicts  the  classic  Radar  Warning  Receiver  (RWR)  and 
shows  that,  in  order  for  the  RWR  to  display  the  correct  symbology,  the 
Emitter  Identification  Data  (EID)  tables'  algorithms  must  be  developed 
based  upon  classified  technical  intelligence  data. 

Elevating  this  one  step  further,  Figure  2-2  depicts  the  Air  Force 
software  reprogramming  concept.  This  concept  is  the  direct  result  of 
the  Air  Force's  attempt  to  offset  the  classic  7-  to  9-year  EW  equipment 


2-3 


EID  TABLE 


Figure  2-1.  Intelligence  -  Engineering  Data  Flow 
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modification  cycle  through  the  use  of  embedded  computers.  Specifically, 
the  concept  depicts  a  change  in  the  threat  being  detected,  collected,  ana¬ 
lyzed,  and  distributed  to  the  Air  Force  users.  At  this  point  the  users, 
in  conjunction  with  WR-ALC,  determine  the  best  software  solution  to  the 
problem,  engineer,  and  disseminate  to  the  field.  As  depicted,  the  entire 
concept  evolves  around  a  very  dynamic  intelligence  loop  wherein  both  the 
users  and  WR-ALC  must  interact  with  the  intelligence  world.  This  inter¬ 
action  requires  not  only  access  to  the  data  but  the  ability  to  influence  the 
collection,  analysis,  and  dissemination  phases. 

Further  compounding  this  issue  and  requiring  additional  AFLC 
involvement  in  the  intelligence  cycle  are  the  following  inherent  EW  soft¬ 
ware  support  requirements: 

•  Preemptive  Engineering  Support.  Currently  WR-ALC,  and 
in  the  immediate  future  SM-ALC,  will  be  involved  in  assist¬ 
ing  the  users  (TAC  and  SAC)  in  preemptively  engineering 
expected  EW  software  changes  based  upon  predicted  and 
highly  classified  technical  intelligence  data.  Through  this 
process  the  Air  Force  EW  community  is  attempting  to 
offset  expected  enemy  wartime  modes  of  operation  and  the 
resulting  impacts  these  modes  would  have  in  U.  S.  EW 
equipment.  More  specifically,  the  Air  Force  is  consider¬ 
ing  building  an  off-the-shelf  library  of  software  changes 
that  can  be  shipped  to  the  field  and  stored  in  anticipation 

of  threat  changes  once  hostilities  are  initiated.  WR-ALC, 
SM-ALC,  and  their  associated  software  engineers  are  an 
integral  part  of  this  Air  Force  process. 

•  Equipment  Modification  and  Development  Support.  His¬ 
torically,  WR-ALC  has  been  actively  involved  in  develop¬ 
ing  the  ALR-46  RWR  family.  Recent  Air  Force  evalua¬ 
tions  of  these  systems  seriously  question  the  ability  of 
these  systems  to  meet  the  expected  threat.  One  of  the 
basic  reasons  for  this  problem  has  been  the  inability  of 
the  developer  to  examine  and  evaluate  highly  sensitive 
intelligence  data.^  SM-ALC,  with  its  emerging  role  to 
support  and  assist  in  the  modification  and  development  of 
U.S,  ground-based  EW  equipment,  has  an  equally  valid 
need-to-know  in  the  area.  In  fact,  most  of  the  newer 
ground-based  EW  equipment  is  designed  to  counter  enemy 
command  and  control  nets.  Information  on  these  command 
and  control  nets  that  is  germane  to  the  development  and 

^Within  the  last  few  years  this  situation  at  WR-ALC  has  improved;  how¬ 
ever,  the  limited  number  of  "cleared"  ALC  personnel  and  the  availability 
of  much  of  the  more  sensitive  data  still  present  serious  problems  in 
accomplishing  the  total  AFLC  mission. 
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support  of  the  ground-based  EW  system,  is  from  sensitive 
and  highly  classified  SIGINT  and  HUMINT  sources. 

In  the  area  of  Airborne  EW  support,  software  support  tools  are  under 
development.  The  Electronic  Warfare  Open  Loop  Simulation  (EWOLS)  and 
the  Flight  Line  Test  Set  (FLTS)  are  examples.  Both  of  these  systems  will 
require  the  ability  to  simulate  large  quantities  of  secret  level  parametric 
intelligence  data.  In  addition,  the  EWOLS  system  will  require  "canned 
yet  valid"  threat  scenario  data.  In  the  case  of  scenario  data,  DOD  direc¬ 
tives  C-4600.  3.  C-3100.  9,  5000.  1,  and  5000.  2  require  that  all  of  this 
type  data  must  be  Defense  Intelligence  Agency  (DIA)  approved.  An 
AF/IN  8  August  1979  letter,  "Threat  Assessment  Development,"  imple¬ 
menting  these  directives,  fails  to  recognize  AFLC's  role  in  this  area; 
however,  it  points  out  that  development  of  this  type  data  is  a  using  com¬ 
mand's  responsibility. 

Equally  demanding  in  this  case  is  the  AFLC's  mission  to  support  fire 
control  radars,  communications  systems  of  the  Seek  Talk  and  JTIDS 
variety,  aircrew  training  devices,  and  command  and  control  systems 
such  as  AW  ACS  and  AABCP.  Of  these,  support  to  fire  control  systems 
of  the  F-15/F-16  variety  may  be  an  immediate  problem.  As  previously 
stated,  the  Soviet  REC  concept  specifically  targets  fire  control  radars 
(Reference  2-2). 

The  vulnerability  of  all  U.  S.  command,  control  and  communications 
systems  to  the  Soviet  REC  is  of  critical  concern  to  both  war  planners  and 
field  commanders.  To  blunt  the  success  of  Soviet  REC  forces  the  DOD 
has  directed  the  development  of  a  Command,  Control,  and  Communica¬ 
tions  Countermeasures  (C^CM)  program.  Specified  requirements  are 
spelled  out  in  DOD  directive  4600.4,  dated  27  August  1979.  The  full 
implementation  of  these  requirements  will  impact  ECS  in  four  of  the  sup¬ 
port  categories:  OFP,  EW,  ATD,  and  C-E.  The  high  flexibility  of  ECS 
software  makes  it  an  excellent  candidate  for  implementing  near-term 
countermeasures  solutions.  Future  C^  systems  will  have  countermeasures 
capabilities  designed- in  during  initial  development.  In  many  cases,  these 
countermeasures  features  will  be  incorporated  into  the  ECS  software. 
Therefore,  in  addition  to  ECS  updates  for  error  correction  and  system 
enhancement,  changes  will  be  driven  by  enemy  actions  and  counteractions 
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to  our  own  REC  program.  As  enemy  REC  intelligence  becomes  available, 

3 

the  ALC's  must  start  preemptive  engineering  on  C  CM  software  updates. 
The  timing  and  frequency  of  these  updates  will  depend  on  enemy  actions 
and  the  availability  of  the  required  intelligence  data. 

One  might  argue  that  providing  such  intelligence  support  is  not  an 
AFLC  responsibility  but  rather  an  AF/IN  or  an  FTD  role.  AFR  200-1 
provides  the  overall  guidance  for  intelligence  support  to  the  various  Air 
Force  major  commands.  This  regulation  states  specifically  that  intelli¬ 
gence  support  is  a  MAJCOM  responsibility,  with  overall  policy  direction 
provided  by  the  ACS/ 1.  In  layman's  language  this  means  that  if  a  MAJCOM 
requires  intelligence  support  it  must  provide  the  manpower,  facilities, 
and  resources  necessary  from  within  its  own  structure. 

Figure  2-3  is  a  top  level  look  at  the  current  impacts  this  new  role 
is  having  on  the  AFLC  mission.  This  quick  appraisal  shows  that  AFLC 
at  both  Warner  Robins  and  Sacramento  should  initiate  immediate  actions 
to  ascertain  the  resources  and  facilities  required  to  support  their  new 
roles.  Caution  should  be  exercised  to  ensure  that  adequate  resources 
and  commitment  are  made  without  going  too  far  in  this  respect.  Accom¬ 
plishment  of  this  appraisal  will  require  an  exhaustive  review  of  the  roles 
of  both  AFLC  and  existing  intelligence  organization.  The  appraisal  should 
include  everything  from  communication  requirements  to  facility  construc¬ 
tion.  Number,  location,  and  clearance  level  of  personnel  must  be  listed 
as  an  essential  part  of  this  effort. 

2.  3  SOFTWARE  SUPPORT  TOOLS 

Given  the  dependency  of  our  avionics  systems  upon  the  use  of  the 
electronic  environment  and  the  determination  of  the  Soviets  to  deny  or 
degrade  this  use,  there  can  be  little  doubt  that  once  hostilities  begin  much 
of  the  jamming  environment  to  which  U.  S.  systems  will  be  subjected  will 
be  new  and  unusual.  Couple  this  with  the  possible  susceptibility  of  our 
avionics  systems  to  jamming  and  the  critical  role  these  systems  play  in 
mission  accomplishment,  and  one  can  envision  a  great  demand  being 
placed  on  AFLC/ALC  to  quickly  modify  and  correct  these  deficiencies. 
Both  preemptive  engineering  and  Quick  Reaction  Software  Capabilities 
(QRSC)  are  alternatives  which  should  be  developed.  Both  of  these  will 
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require  development  of  additional  software  support  tools.  From  a  fire 
control  radar  view,  a  requirement  exists  to  develop  the  tools  necessary 
to  stimulate  the  various  systems  with  realistic  and  likely  ECM  techniques. 
Using  this  approach,  sensitive  system  design  areas  could  be  monitored 
along  with  overall  system  performance  for  effectiveness  and  vulnerability 
data.  Based  upon  this  data,  alternative  ECCM  "fixes"  both  in  hardware 
and  software  could  be  either  preemptively  engineered  or  developed  in 
real  time  using  a  QRC  type  approach.  However,  obtaining  the  tools  alone 
is  not  the  total  answer.  The  dynamics  of  the  electronic  warfare  arena 
forces  the  various  Air  Force  communities  (Intelligence,  Development, 
Operational,  and  Logistical)  to  work  hand-in-hand  in  order  to  stay  abreast 
of  the  "Counter  Countermeasures  EW  Chess  Game.  "  As  a  result  of  this 
"move- countermove  game"  preemptive  engineering  and  QRC  reactions 
must  become  a  way  of  life  in  the  support  arena. 

Preemptive  engineering  in  this  area  starts  with  fragmented  and 
multi- sourced  intelligence  data.  This  data  reflects  either  adversary 
intentions  and/or  hard  technical  data  on  the  various  pieces  of  threat 
equipment,  either  in  the  field  or  in  development.  Using  this  data  com¬ 
bined  with  U.  S.  equipment  vulnerabilities  and  technologies,  engineering 
estimates  as  to  the  expected  adversary  intentions  and  capabilities  can  be 
made.  Based  upon  these  estimates,  countermeasures  techniques  and 
alternatives  can  be  preemptively  engineered  and  either  installed  or  placed 
in  storage  for  future  use.  To  ensure  community  acceptance  of  preemp¬ 
tively  engineered  approaches  and  to  improve  the  reliability  of  the  threat 
estimates,  a  team  approach  involving  all  the  key  players  is  required. 

This  approach  necessitates  that  all  players  have  access  to  all  relevant 
data  to  include  sensitive,  all- source  intelligence  information. 

From  an  ALC  support  role,  even  more  urgent  than  the  requirement 
to  assist  in  preemptive  engineering  work  is  the  necessity  to  develop  and 
maintain  a  Quick  Reaction  Capability  (QRC)  for  ECCM  modification  to 
fire  control  radars  of  the  F-15/F-16  variety.  As  cited  earlier,  several 
high  level  studies  have  pointed  out  the  fact  that  these  systems  are  a  spe¬ 
cific  target  of  the  Soviet  REC  concept.  As  such,  there  will  be  a  continu¬ 
ous  requirement  to  detect,  predict,  evaluate,  and  modify  these  systems 
if  they  are  to  remain  combat  effective. 
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2.4  RECOMMENDATIONS 

Initiate  action  to  provide  a  stimulus  and  effectiveness  monitoring 
capability  for  key  avionics  systems.^  These  actions  should  include: 

•  Investigation  of  incorporating  basic  stimulus  and  monitor¬ 
ing  equipment  as  an  integral  part  of  each  AISF.  Should 
this  approach  be  taken,  an  overall  AFLC  management  over¬ 
sight  program  should  be  implemented  to  ensure  that  the 
stimulus  and  the  monitoring/data  reduction  within  each 
AISF  is  standardized,  that  the  results  are  transferrable, 
and  that  the  intelligence  data/stimulus  waveforms  are 
"valid"  and  universally  used  throughout  the  ALC's. 

•  Investigation  of  the  feasibility  of  using  an  Electronic  War¬ 
fare  Open  Loop  Simulation  (EWOLS)  similar  to  that  being 
developed  at  WR-ALC/MMR.  Using  this  approach,  the 
idea  would  be  to  expand  the  current  EWOLS  concept  to 
include  the  capability  to  generate  various  jamming  wave¬ 
forms.  Such  a  capability  could  be  directly  applicable 
within  WR-ALC/MME,  SM-ALC,  and  OO-ALC. 

At  the  same  time,  emphasis  should  be  placed  on  documenting  and 
developing,  as  an  integral  part  of  the  stimulus /monitor ing  equipment,  a 
preemptive  engineering  and  QRC  support  capability.  Under  this  concept, 
the  stimulus /monitoring  equipment  not  only  serves  to  stimulate  and  eval¬ 
uate  the  baseline  data/avionics  system,  but  also  allows  the  evaluation  of 
changes  to  both  the  stimulus  and  the  avionics  system  in  a  preemptive 
engineering  and  QRC  development /test  role.^ 

Fire  control  radars  and  their  associated  core  of  trained  personnel 
should  be  ranked  as  first  priority  among  avionics  systems  to  be  augmented 
with  the  aforementioned  support.  Rationale  for  this  ranking  is  based  upon 
the  following: 

•  These  systems  are  currently  deployed  in  the  field.  With 
the  development  of  the  "beyond  visual  range"  air-to-air 


+Key  systems  should  include,  but  not  be  limited  to,  terrain  avoidance/ 
terrain  following  radars,  fire  control/Nav  Aid  radars,  IFF,  and  selected 
communications  system.  Particular  emphasis  should  be  given  to  the  F- 15, 
F-16,  E-3A,  F-lll,  and  JTIDS  systems. 

^Exact  technical  details  and  limitations  in  obtaining  the  capabilities  dis¬ 
cussed  thus  far  have  not  been  investigated.  Therefore,  investigation  of 
these  capabilities  should  be  the  first  action  taken  in  pursuing  this  area. 
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missiles,  it  is  essential  that  these  systems  be  capable  of 
undegraded  performance  in  an  ECM  environment. 


•  Thu  niMm-ru.il  nupe  rio  r  ity  of  the  Soviets  in  a  Central 
Kuropean  environment  requires  the  F-15/F-16  systems 
be  able  to  effectively  engage  with  extended  "beyond  visual 
range  missiles"  and  to  do  so  with  a  high  confidence  kill 
probability  on  a  single  shot  basis. 

•  Soviet  REC  is  targeted  against  U.  S.  fire  control  radars. 

One  of  the  specific  objectives  of  this  targeting  approach  is 
to  deny  U.  S.  aircraft  the  advantage  of  long  range  directed 
air-to-air  missile  engagements. 

Train  and  maintain  within  each  support  facility  a  core  of  expertise 
in  the  areas  described  in  the  preceding  paragraphs. 

Conduct  an  extensive  review  of  the  current  and  future  ALC's  mis¬ 
sion  and  from  this,  document  their  requirement  for  the  use  and  storage 
of  classified  data  to  include  both  "Friendly/Blue"  and  foreign  intelligence 
data.  WR-ALC  and  SM-ALC  should  receive  first  priority  for  this  review 
due  to  their  extensive  work  in  the  area  of  electronic  warfare.  This  should: 

•  Identify  the  type  and  classification  of  the  various  AL-C  ECS 
support  facilities  as  a  function  of  both  the  classified  intelli¬ 
gence  material  handling /storage  and  the  classified  nature 
of  the  "Friendly /Blue"  systems.  This  effort  should  include 
not  only  a  review  of  the  overall  facility  classification,  but 
also  identification  of  required  work  areas  and  conference 
facilities. 

•  Analyze  and  identify  the  type,  number,  and  level  of  classi¬ 
fication  of  the  personnel  required  to  support  each  ALC  in 
this  area. 

•  Document  and  implement  appropriate  HQ  AFLC  direction 
in  the  area  of  specific  responsibilities  for  obtaining  and 
providing  the  required  intelligence  support  at  the  various 
ALC's.  Specific  consideration  should  be  given  to  publica¬ 
tion  of  an  AFLC  implementation  regulation  for  AFR  200-  1. 

•  Based  upon  the  above  work,  develop  a  long-range  plan  for 
obtaining,  storing,  and  working  with  foreign  intelligence 
data  command- wide. 

In  coordination  with  operational  commands  and  the  intelligence  com¬ 
munity,  develop  a  concept  of  operations  for  reprogramming  critical  mis¬ 
sion  embedded  computer  systems.  The  EWIR  concept  now  used  for  EW 
reprogramming  should  be  used  as  a  guide. 
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3.  PERSONNEL  AND  TRAINING 


3.  1  BACKGROUND 

Suffusing  the  personnel  and  training  elements  of  computer  resources 
are  issues  which  should  be  given  proper  consideration  in  ECS  support 
planning  to  ensure  an  AFLC  ability  to  satisfy  the  capability,  compatibil¬ 
ity,  interoperability,  reliability,  maintainability,  and  logistics  support- 
ability  requirements  dictated  by  the  computer-laden  weapon  systems  enter¬ 
ing  the  USAF  inventory  in  the  1980-  1990  timeframe.  These  issues,  which 
bear  upon  all  levels  of  software  Operation  and  Support  (O&S)  conduct  and 
management,  draw  focus  upon  the  ability  to  plan,  justify,  recruit,  train, 
and  retain  organic  personnel  in  sufficient  number  and  proficiency  to 
effectively  and  economically  carry  out  the  AFLC  software  O&S  mission. 

The  quantity  of  organic  personnel  required  to  perform  the  AFLC 
software  O&S  job  is  projected  to  increase  at  an  average  rate  of  approxi¬ 
mately  10  percent  per  annum  through  at  least  the  next  six  years,  to  an 
FY  86  requirement  of  3,  536.  This  FY  86  level,  almost  70  percent  higher 
than  the  FY  80  requirement,  will  cost  approximately  $92  million  per  year 
based  upon  current  year  dollars.  Were  all  ECS  software  O&S  functions, 
which  can  be  regulation  (Reference  3-1)  be  contracted  to  be  performed 
under  contract  to  industry,  more  than  1,  200^,  organic  personnel  would 
still  be  required  in  FY  86.  Mission  readiness  and  QRC  requirements 
[e.g.,  as  specified  in  AFR  400-33,  and  safeguards  against  illegal 
Government-contractor  employer- employee  relationships  as  specified 
in  Defense  Acquisition  Regulations  (DAR)  and  the  Federal  Personnel 
Manual  (FPM)]  are  expected  to  increase  this  minimal  organic  level  by 
at  least  100  percent.  The  point  to  be  made  is  that  AFLC  must  acquire 
and  retain  substantial  numbers  of  highly  skilled  digital  engineers  over  the 
next  six  years  under  any  support  concept. 

Authorized  manning  levels  significantly  lag  behind  required  manning. 
Approximately  2,  100  personnel  (Table  3-1)  are  required  in  FY  80,  whereas 


^Using  algorithms  presented  in  Air  Launched  Cruise  Missile  Generic 
Logistic  Decision  Tree  package  submitted  by  AFLC  HQ  for  DOD  New 
Start  Management  approval. 
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Total  ALC  Projected  Organic  Manpower  Requirements  for  ECS's 


only  1,  260,  or  40  percent  less,  are  actually  authorized  (Table  3-2). 

These  are  distributed  across  MM,  MA,  and  AC.  It  should  be  noted  that 
this  organic  level  is  augmented  by  approximately  $25  million  of  contractor 
engineering  support  in  FY  80  EEIC  583  funds  alone. 

Table  3-2.  Authorized  ECS  Slots,  April  1980 


ALC 

Authorization 

SA- ALC 

122 

OO- ALC 

225 

SM-ALC 

303 

WR- ALC 

481 

OC- ALC 

135 

TOTAL 

1,  266 

The  task  of  authorizing  and  acquiring  the  quantity  and  quality  of  per¬ 
sonnel  required  is  largely  the  tip  of  the  iceberg,  with  training  and  reten¬ 
tion  difficulties  being  the  submerged  portion  of  the  overall  problem. 

3.2  DISCUSSION 

Illustrated  in  Figure  3-  1  are  the  key  elements  required  in  develop¬ 
ing  and  retaining  a  manpower  capability  for  software  O&S;  personnel 
acquisition,  training,  and  retention.  Each  of  these  elements  represents 
a  chief  source  of  the  issues  which  shroud  the  AFLC  software  O&S  per¬ 
sonnel  and  training  arena. 

3.  2.  1  Personnel  Acquisition 

Within  the  personnel  acquisition  process  lie  three  interrelated  areas 
which  prompt  issues.  These  are:  (1)  manpower  requirements /definitions 
and  planning,  (2)  the  AFLC  manpower  justification/authorization  process, 
and  (3)  recruiting. 

3.2.  1.  1  Manpower  Requirements /Definition  and  Planning 

The  issues  affecting  or  emanating  from  this  area  are  discussed  in 
the  following  paragraphs. 

3.2. 1.1.1  Common  Staffing  Support  Concept.  The  staffing  software 
support  concept  used  and  planned  for  at  each  ALC  and,  by  and  large  for 
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support  concept  used  and  planned  for  at  each  ALC  and,  by  and  large  for 
each  program,  varies  from  total  (100  percent)  organic  [e.g.,  E-3A  at 
OC-Al,C  where  54  Government  Personnel  Equivalents  (PE's)  and  no  con¬ 
tractors  arc  projected)  to  minimal  Government  staffing  (e.g.,  F/FB-111 
at  SM-ALC,  where  approximately  15  Government  personnel  are  utilized 
with  60  contractor  PE's).  Recognizing  that  limited  manpower  authoriza¬ 
tions  and  funding  inadequacies  have  largely  bred  such  diversity,  maximum 
use  of  the  data  extracted  from  these  various  mixes  should  be  made  to 
ensure  that  the  approaches  selected  in  the  future  reflect  an  optimum  mix. 
Future  O&S  concepts  should  be  premised  upon  a  standard  which  considers 
the  characteristics  of  the  ECS  itself,  the  environment  in  which  it  will  be 
used  and  supported,  as  well  as  economic /readiness  issues.  It  should  be 
noted  that  OMB  Circulars  A-76  and  109,  DODD  4100.  15,  AFM  400-2, 

AFR  400-  33,  AFM  26-1,  AFLCR  400-XX  and  other  guidance,  while 
attempting  to  partition  Government  (including  readiness)  functions  from 
contractable  functions  and  Civil  Service  functions  from  military  functions, 
leave  sufficient  tenuousness  in  their  interpretation  to  facilitate  wide  mix 
layers. 

Because  of  competition  between  agencies  (user /SPO/ AFLC / AF ALD/ 
ALC/interservices)  for  software  O&S  and  because  of  SPO  interests  to 
minimize  front  end  costs  (viz.  equipment,  but  manpower  indirectly),  ALC 
organic  requirements  are  not  always  universally  supported.  In  addition, 
pre-PMRT  funding  and  manpower  are  not  available  to  properly  define  and 
"sell"  the  AFLC  support  concept  for  a  given  ECS  to  the  SPO,  the  user, 
and  higher  headquarters  (see  Section  3.  2.  1.  1.  3).  As  a  result  of  these 
difficulties  the  credibility  of  the  ALC  requirements  is  weakened,  thus 
diminishing  the  likelihood  of  obtaining  sufficient  authorization  to  imple¬ 
ment  the  concept. 

In  the  past,  the  system  management  support  given  to  the  software 
O&S  posture  is  frequently  more  tacit  than  aggressive.  This  less-than- 
full  coordination  adds  to  the  already  weakened  AFLC  position. 

3.  2.  1.  1.  2  Integrated  ECR  Planning.  While  the  CRISP  and  O/S  CMP 
are  designed  to  be  the  chief  source  of  integrated  resource  planning,  both 
are  yet  to  be  recognized  as  officially  approved  plans  to  which  all  resource 
requests  are  linked  and  substantiated.  Instead,  each  resource  must  be 
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independently  requisitioned  through  previously  existing  channels,  hope¬ 
fully  in  parallel.  The  CRISP  has  thus  become  a  "square"  to  be  filled 
to  avoid  an  IG  write-up.  Unless  approval  has  been  given  to  the  MCP  or 
AISF  equipment,  approval  of  the  manpower  package  may  be  forestalled, 
or  MCP  approval  may  pend  manpower  authorization.  Tendencies  are  to 
use  the  lack  of  approval  of  one  resource  as  justification  to  deny  another, 
creating  a  "chicken-and-egg"  microcosm. 

3.  2.  1.  1.  3  Common  Manpower  Requirement  Baseline.  Currently 
no  single  methodology  for  estimating  manpower  is  recognized  by  AFLC. 
Consequently,  each  ALC  and,  by  and  large  each  program,  employs  a 
different  means.  This  results  in  wide  and  various  manning  requirements 
across  and  within  the  ALC's  which  do  not  correlate  with  computer  pro¬ 
gram  change,  size,  complexity,  programming  language,  or  other  char¬ 
acteristics  which  are  commonly  thought  to  affect  software  O&S  require¬ 
ments.  For  example,  the  E-3A,  which  in  terms  of  equivalent  instructions 
is  approximately  five  times  the  size  of  and  equal  in  complexity  to  the  F-15 
software,  is  planned  to  be  supported  by  30  percent  fewer  people  than  the 
F-15  software.  Also,  the  EW  software  on  three  of  the  five  USAF  fighters 
requires  more  manpower  to  support  than  does  the  corresponding  fighter 
OFP's.  These  facts  lead  one  to  believe  that  common  criteria  is  needed 
to  determine  more  realistic  manpower  requirements. 

While  many  software  studies  have  been  conducted  or  are  under  cur¬ 
rent  contract,  post- deployment  weapon  system  Embedded  Computer  Sys¬ 
tems  O&tS  has  largely  gone  untreated;  the  driving  interest  has  been  in  the 
front  end  (software  development),  rather  than  life  cycle  costs.  With 
forecasts  indicating  an  ever-  increasing  O&Scost,  this  emphasis  should 
be  reoriented.  The  software  support  cost  study,  recently  completed 
under  AFAL  contract  to  Hughes,  shows  promise  of  providing  valuable 
baseline  data  and  methodology  in  this  regard.  The  follow-on  effort  on 
this  study,  recently  awarded  to  SCI,  should  provide  a  set  of  key  param¬ 
eters  which  dictates  life  cycle  software  costs. 

In  addition,  the  pre-PMRT  planning  for  ALC  manpower  requirements 
for  a  given  system  is  developed  in  advance  of  software  definition  and,  con¬ 
sequently,  in  the  absence  of  an  in-depth  assessment  of  the  O&S  job. 

Usually  generated  as  part  of  the  CRISP  studies,  these  initial  requirements 
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often  find  their  way  into  more  formally  defined  manpower  requirements 
(viz.  ,  via  the  MES  Detachment  Form  AF  602's,  etc.  ).  Tendencies  are 
to  freeze  these  requirements  early,  ignoring  the  newer  O&S-peculiar 
data  as  it  becomes  available  for  fear  that  such  a  change  would  reflect 
uncertainty  or  a  lack  of  knowledge,  either  of  which  would  endanger  chance 
of  approval.  These  largely  unfounded  preliminary  manpower  requirements 
consequently  must  be  lived  with. 

3.2.  1.  1.4  Common  Tasking  and  Work  Breakdown  Structure  (WBS). 

No  generally  accepted  delineation  of  tasks  or  task  structuring  exists 
across  the  ALC's  for  software  O&S.  Consequently,  the  requirements  for 
numbers  and  kinds  of  personnel  to  satisfy  such  a  structure  vary  widely 
for  what  appears  to  be  basically  the  same  job.  The  ALC  Computer 
Resources  Branch  (MMEC)  sectional-level  structure  being  dissimilar 
at  each  ALC  erroneously  suggests  that  each  ALC  Computer  Resource 
Branch  is  performing  a  different  function.  The  roles  and  functions  within 
each  ALC  across  MMIR,  MMAR,  MA-T,  MMEC,  and  ACD  organization 
likewise  reflect  little  commonality.  AFLCR  23-42  and  23-43  appear  too 
general  to  assist  in  defining  a  common  WBS.  The  effectiveness  and  effi¬ 
ciency  offered  by  each  WBS  concept  being  tested  should  be  carefully 
studied  to  arrive  at  an  optimum  approach  for  each  type  ECS  supported. 

3.2.  1.  1.5  Consistent  Entry  Level,  Skill  Level,  Grade  Classification. 
Largely  as  a  result  of  having  no  common  software  O&S  task  definitization 
and  WBS,  as  well  as  because  of  past  manpower  authorization  ceilings,  the 
entry  level,  skill  level,  and  grade  structure  mix  varies  across  the  ALC's. 
While  many  of  the  software  O&S  functions  can  be  performed  by  entry  level 
personnel  with  limited  training,  certain  of  the  engineering  tasks  involved 
in  the  decision  process  can  only  be  performed  by  a  well  experienced  cadre 
of  personnel,  adept  in  weapon  system  engineering  and  computer  science. 

ECR  classifications  are  emerging  rather  than  being  identified.  The 
personnel  skill  pool  having  experience  in  software  is  relatively  small  and 
camouflaged  by  experience  crediting  procedures  which  do  not  distinguish 
this  experience  from  other  more  general  skills.  Local  practice  appears 
to  be  to  classify  certain  software  positions  along  the  lines  of  the  more 
general  skills.  To  reach  candidates  of  appropriate  experience,  "under 
the  line"  specialties  (e.  g.  ,  logistics  management  specialist/software)  or 
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unique  promotion  evaluation  patterns  are  used.  Procedures  addressing 
"applicants  only"  candidates  are  costly  and  difficult  to  manage  and  staff. 
These  difficulties  are  greater  for  GS-12  and  above  levels  because  career 
board  procedures  must  be  followed. 

Three  different  approaches  to  skill  acquisition/accrual  appear 
across  the  ALC's:  (1)  a  hiring  of  predominately  entry  level  electrical 
engineers  (e.  g.  ,  GS-5)  and  an  elevation  of  skill  level  through  training 
to  target  grade  (e.  g.  ,  GS-  1 1)  in  two  to  three  years,  (2)  a  hiring  of  pre¬ 
dominately  industrially  or  governmentally  experienced  engineers  (e.g.  , 
at  GS- 11/12  level),  and  (3)  the  cross-training  of  existing  GS- 11/12  engi¬ 
neers  from  other  disciplines  to  computer  program  O&S.  It  should  be 
noted  that  this  spread  in  approach  largely  results  from  the  ease  with 
which  staffing  can  be  accomplished  rather  than  by  design. 

The  target  grade  mix  varies  across  the  ALC's,  some  having  a  pre¬ 
ponderance  of  GS-5's  and  GS-7's  and  others  are  predominately  GS-  12's. 
PACER  SPAN,  instituted  in  hope  of  "equalizing"  incongruencies  in  this 
regard,  has  brought  about  other  difficulties  to  be  discussed  in  Sec¬ 
tion  3.  2.  1.  3. 

With  perhaps  the  exception  of  OO-ALC  (which  draws  upon  ACD  sup¬ 
port),  the  ALC's  approach  to  skill  development  is  to  train  electrical  engi¬ 
neers  to  be  software  engineers.  While  many  of  the  software  O&S  disci¬ 
plines  require  EE  background,  expertise  in  computer  science  appears  to 
be  overlooked. 

The  common  goal  of  these  approaches  should  be  to  satisfy  econom¬ 
ically  a  uniform  set  of  software  O&S  capability  requirements  (e.g.  ,  a 
weapon  system  or  ECS  core  capability,  augmented  by  generic  capabilities 
in  program  design,  coding,  debugging,  testing,  etc.  ).  Consequently,  a 
blend  of  these  approaches  versus  reliance  upon  a  single  approach  appears 
most  reasonable,  with  the  selected  alternative  for  a  given  situation  being 
one  which  calls  for  the  least  number  of  personnel  of  the  lowest  skill  levels 
deemed  sufficient.  The  key  rests  in  the  definition  of  skills  required. 

3.2.  1.  1.6  Integrated  Support  Across  ECS's.  Few  incentives  exist 
for  consolidating  resources  across  systems  within  a  given  ALC,  needless 
to  say,  across  ALC's.  Although  AFR  800-  14  touches  upon  such  a  goal, 
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the  coalescing  of  human  resources  can  prove  to  be  self-defeating  from  an 
isolated  ALC  point  of  view.  For  example: 

•  Personnel  and  equipment  costs  are  reduced  because  of 
the  cross-utilization  of  resources,  consequently  lowering 
the  chances  of  obtaining  the  manpower  needed;  vis-a-vis 
"the  more  you  ask  for,  the  more  you  get,  "  push-pull  logic 

•  Acquisition  of  any  equipment  used  to  satisfy  the  require¬ 
ments  for  more  than  one  system  stands  to  be  a  prime  sus¬ 
pect  for  800  versus  300  series  debate;  it  is  vulnerable  to 

a  "general  purpose" tag 

•  Disapproval  of  any  one  of  the  elements  of  a  consolidated 
approach  jeopardizes  the  support  posture  for  all  systems. 

As  a  result  of  these  shortfalls,  the  incentive  is  to  require  a  complete, 
standalone  capability  for  each  system  (subsystem)  requiring  support. 
Largely  because  of  this,  programmatical/weapon  system  management 
interests  are  usually  in  direct  opposition  to  consolidation  with  other 
programs. 

Aside  from  the  more  obvious  economic  reasons,  some  of  the  more 
latent  benefits  of  cross-training  personnel  across  ECS's  and  across  ALC's 
are: 

•  Experienced  personnel  from  one  ECS  can  be  utilized  to 
assist  in  the  start-up  support  of  another  in  a  temporary 
capacity 

•  Personnel  from  a  shut-down  AISF  (e.  g.  ,  in  a  wartime 
situation)  may  be  used  to  operate  another  AISF  still  in 
operation 

•  Personnel  centrally  located  at  a  given  ALC  may  support 
remote  off- site  laboratory/field  teams  on  a  TDY  basis 

•  With  the  more  advanced  networking  tools  being  introduced 
day-to-day,  problems  can  be  resolved  via  real  time  con¬ 
sultations  with  expertise  located  at  other  ALC's 

3.2.  1.  1.7  Contingency  Planning.  In  ECR  planning  (CRISP's,  ILSP's, 
etc.),  organic  personnel  requirements  for  ALC  software  O&S  are  seldom 
accompanied  by  alternative  plans  to  be  exercised  in  the  event  that  organic 
levels  and  skills  cannot  be  obtained  in  the  time  frame  necessary.  Decision 
points  or  checkpoints  along  the  way  (to  assess  the  appropriateness  of 
initial  or  earlier  planning)  are  not  a  standard  ingredient  in  current 
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planning.  Consequently,  surprises  arise  impacting  fiscal  planning  and 
requiring  budgetary  reprog  ramming. 

3.  2.  1.  2  Justification/ Authorization  Process 

The  authorization  of  manpower  slots  is  a  slow,  tedious  and  some¬ 
times  fruitless  process  for  the  ALC's.  No  clearly  discernible  path  exists 
between  the  many  manpower  justification  exercises  and  the  authorization 
of  slots.  The  interface  between  engineering  and  the  MES  Detachment  is 
equally  murky. 

Manpower  requirements  are  submitted  annually  (usually  more  than 
once)  in  various  forms  and  through  various  channels.  The  requirements 
are  generally  established  as  a  result  of  historical  information  and  judgment 
calls.  How  these  various  forms  relate  to  each  other  is  not  clear.  As 
they  are  not  all  focused  on  the  same  goal,  different  requirement  levels 
are  often  reported  for  the  same  effort.  Whatever  the  method,  the  require¬ 
ments  are  difficult  to  defend  and  easily  refuted.  Much  paper  and  huge 
amounts  of  time,  energy,  and  effort  are  necessary  to  "push  through"  a 
manpower  requirement  which  finally  results  in  an  allocation  of  a  portion 
of  the  slots  requested.  In  short,  only  subjective  criteria  appear  to  be 
used  in  the  annual  AFLC  manpower  "push-pull"  exercise  designed  to  affix 
slot  authorizations  at  each  ALC. 

While  it  is  not  clear  how  additional  manpower  approved  under  the 
New  Start  (AFM  26- 1)/Generic  Logistic  Decision  Tree  [AFLCR  400-XX 
(Draft)  Task  Order  78-4]  process  will  be  administered,  it  also  seems  to 
add  a  new  dimension  of  confusion  to  the  log  jam  of  requirements  already 
registered  against  a  largely  fixed  AFLC  manpower  ceiling. 

In  the  absence  of  approved  manpower  requirements  (even  though 
validated  by  the  local  MES  Detachment),  overhire  positions  have  been 
used  to  recruit  against.  Overhire  positions  must  then  be  "firmed  up" 
by  the  reallocation  of  manpower  reserves.  As  a  result,  some  employees 
are  brought  in  at  entry  levels  under  overhire/pipeline  positions  which 
can  only  be  made  firm  through  attrition  in  other  areas  within  D/MM. 

While  occasionally  misused,  this  "buffer"  approach  to  manpower  buildup 
has  proven  to  be  a  valuable  alternative. 
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When  personnel  requirements  are  submitted  and  ultimately  author¬ 
ized,  the  acquisition  program  which  generated  the  requirements  is 
"down  the  road"  and  ALC  engineering  action  requirements  in  support  of 
the  effort  already  exist  in  participation  on  Computer  Resources  Working 
Groups  (CRWG's),  in  preparation  of  CRISP  and  O/S  CMP,  in  PDR,  CDR, 
test,  and  audit  activities,  etc.  Thus,  the  more  experienced  personnel 
must  attend  to  such  actions  while  new  people  are  hired  and  brought  up  to 
speed.  Adequate  training  of  new  people  may  take  one  to  three  years. 

The  experienced  personnel  are,  therefore,  in  a  "do  the  best  you  can" 
situation.  This  often  results  in  either  insufficient  attention  to  the  system 
in  acquisition  or  neglect  of  already  existing  systems  requiring  support. 

This  presents  something  of  a  paradox  in  that  the  new  system  must  be 
coming  along  in  order  to  justify  new  personnel  and  the  personnel  must  be 
on  board  and  trained  to  actively  support  the  new  system  during  acquisition 
phases. 

3 .  2 .  1 .  3  Recruiting 

The  demand  for  experienced  co mpute r- o r iented  engineers  and  sci¬ 
entists  far  exceeds  the  supply  today,  both  for  industry  and  the  govern¬ 
ment.  Industry  tends  to  pay  more;  it  pays  for  potential  employee  visits 
to  plants  and  often  offers  more  and  better  benefits.  Although  some  com¬ 
panies  make  demands  on  their  employees  (e.g.,  loyalty  overtime  without 
pay,  etc.  ),  the  government  usually  is  outbid  in  the  employee  marketplace. 
Additionally,  there  appears  to  be  a  degree  of  reluctance  of  some  to  become 
a  civil  servant.  Restrictive  hiring  practices  (grade  limits,  educational 
restrictions,  etc.  )  further  constrict  the  available  pool.  Coupling  these 
shortfalls  with  the  government's  long  and  drawn  out  recruiting/offer 
authorization  process  results  in  an  exceedingly  slow,  if  not  insurmountable, 
organic  manpower  buildup.  Some  fine  efforts  to  glamorize  the  organic 
role  through  marketing  (e.g.,  brochures  and  nationwide  advertisement) 
have  paid  off  in  acquiring  some  of  the  lesser  skills  required.  While  most 
of  the  ALC's  have  been  successful  in  acquiring  personnel  in  the  quantity 
necessary,  their  success  at  acquiring  the  more  experienced,  energetic 
software  engineer  varies,  depending  upon  the  labor  pool  from  which  they 
are  selected. 


Considering  that  generally  the  ALC's  do  not  have  a  recognized 
recruiting  activity  per  se,  and  in  the  absence  of  integrated  recruiting 
plans,  the  ALC's  have  done  remarkably  well  in  acquiring  personnel. 

3.  2.  2  T raining 

Upon  being  authorized  manpower  slots,  the  government  organization 
is  expected  to  immediately  fill  them  with  highly  qualified  and  experienced 
individuals  who  begin  at  once  to  produce.  Unfortunately,  even  when  the 
government  is  able  to  induce  well  qualified  individuals  with  some  expe¬ 
rience  into  joining  the  fold,  an  orientation  and  learning  process  of  up  to 
a  year  or  more  is  necessary  before  these  personnel  are  fully  acquainted 
with  the  government's  specific  systems  and  software  and  with  the  Air 
Force  way.  When  such  a  position  is  filled  with  entry  level  personnel,  the 
process  takes  from  three  to  five  years.  The  training /learning  process 
consists  of  working  with  journeyman  level  and  lead  engineers,  general 
on-the-job  training,  service  schools,  and  formal  courses  through  Air 
Training  Command  (ATC). 

3.  2.  2.  1  Training  Source  Selection 

Finding  acceptable  training  sources  for  specific  systems  / softwa re 
and  funding  for  training  are  delaying  factors,  and  the  time  consumed  in 
arranging  for  and  obtaining  such  training  stretches  the  learning  period 
into  a  long  term  effort. 

Often  only  a  contractor  involved  in  the  development  of  the  software 
is  in  a  position  to  provide  adequate  training  to  those  who  must  support  it. 
Frequently,  it  is  found  that  the  contractor  has  not  recognized  such  a  train¬ 
ing  requirement  to  prepare  for  it  in  that  his  knowledgeable  personnel  are 
dedicated  to  design  and  development  efforts  and  cannot  be  released  to 
prepare  for  and  conduct  training  programs.  This  results  in  the  con¬ 
tractor  (if  he  responds  at  all)  attempting  to  bring  some  of  his  other  per¬ 
sonnel  up-to-speed  hurriedly  and  in  a  rather  catch- as  -  catch- can  manner 
so  that  these  people  can  conduct  the  training.  The  acceptability  of  this 
depends  upon  various  factors  such  as  qualifications  and  teaching  ability 
of  the  selected  instructors,  the  complexity  of  the  subject,  and  how  much 
they  are  able  to  absorb  within  the  time  frame  permitted.  Another  diffi¬ 
culty  in  this  area  arises  when  contractors  respond  with  no-bids  or  limited 


proposals  because  of  proprietary  implications  involving  the  software  or 
its  documentation  or,  in  sorpe  instances,  software  design  or  troubleshoot¬ 
ing  aids  and  company  methods  and  support  tools. 

3.  2.  2.  2  Firm  Training  Plans 

A  lion's  share  of  AFLC  training  problems  appears  to  be  brought 
about  by  an  absence  of  firm  training  plans/procedures,  combined  with 
recurring  delays  in  establishing  any  kind  of  reasonably  credible  training 
schedule.  For  example,  on  E-3A  requests  for  software  training  were  for¬ 
warded  to  ATC  as  early  as  1975.  A  13-week  general  lead-in  course  was 
derived  and  is  repeatedly  taught  by  ATC  personnel  so  that  all  personnel 
can  take  advantage  of  it  as  a  prerequisite  to  individual  courses  on  each 
specific  piece  of  software.  A  short  course  for  E-3A  software  manage¬ 
ment  personnel  was  contracted  to  Boeing  and  was  taught  by  Boeing  in  first 
quarter  1978  on  the  system  maintenance  computer  program  fault  trees. 
Formal  training  for  the  radar  software,  diagnostic  and  pre-mission  readi¬ 
ness  software,  microcode,  4PI  hardware,  and  navigational-guidance  soft¬ 
ware  is  yet  to  be  scheduled. 

Planning  for  other  actions  to  fit  around  the  training  is  difficult  to 
accomplish.  The  formal  training  unknowns  often  detract  from  efforts  to 
procure  contractor  services  in  other  areas  because  of  a  fear  of  conflict 
in  schedules.  Uncertainties  in  the  training  planning  are  not  only  a  matter 
of  when,  but  of  whether  it  will  take  place  at  all. 

3. 2. 2.  3  Training  Funds 

Overall  Air  Force  training  funds  projections  (including  TDY)  seem 
to  either  be  underestimated  or  are  drastically  cut  in  the  face  of  funds 
austerity.  Thus,  ATC  defers  much  training  to  a  following  fiscal  year. 
Slippages  then  accumulate  as  new  requirements  each  year  add  to  past  year 
deferred  training,  creating  a  compounding  set  of  unsatisfied  training 
requirements. 

3.  2.  2.  4  Training  Schedules 

Scheduling  training  is  a  problem  area  not  only  from  the  funds/ 
instructor  availability  standpoint,  but  from  an  overall  program  synchroni¬ 
zation  point  of  view.  First,  personnel  must  be  available  to  train;  secondly. 
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equipment  and  systems  must  be  available  for  practice  exercises  outside 
of  the  classroom  desktop  environment;  and  thirdly,  an  attempt  must  be 
made  to  define  a  schedule  which  will  not  incur  unacceptable  training  over¬ 
laps  (since  personnel  are  sometimes  cross-trained  in  more  than  a  single 
computer  program)  and  which  will  fit  in  with  informal  OJT  and  with  other 
required  activities  (such  as  design  reviews  and  audits,  technical  inter¬ 
change  meetings,  participation  in  test  efforts,  etc.  ). 

3.2.3  Personnel  Retention 

The  government  has  historically  retained  many  career  people  who 
spend  their  working  lives  from  start  to  finish  in  the  civil  service  ranks. 
Recent  indications  show,  however,  that  such  is  not  the  case  for  activities 
within  the  computer  arena.  On  the  contrary,  the  trend  in  this  area  appears 
to  be  a  training  ground  for  junior  engineers  who  leave  for  greener  pastures 
lust  as  they  reach  a  truly  productive  stage.  The  lack  of  promotional  oppor¬ 
tunities.  non-competitive  salaries,  job  dissatisfaction,  and  insufficient 
opportunity  for  professional  development  are  generally  given  as  major 
reasons  for  engineers  voluntarily  leaving.  Software  engineers  charac¬ 
teristically  like  to  become  involved  in  laboratory  functions,  to  get  into 
design  and  prototype,  not  to  be  bothered  with  administrative  procedures, 
to  avoid  red  tape  and  paperwork,  and  to  have  ready  access  to  equipment, 
parts,  materials,  literature  and  so  on.  Government  service,  viz.  in  AFLC. 
tends  to  pay  less,  require  more  paperwork,  levy  restrictions  and  red  tape 
in  obtaining  work  materials,  and  frustrate  every  endeavor  to  accomplish 
something.  More  often  than  not,  it  seems  that  a  continuing  series  of 
restudies  and  rejustifications  is  required.  While  these  frustrating  situa¬ 
tions  occur  in  industry,  they  appear  to  be  less  visible  and  have  less  impact 
on  the  journeyman  level  engineers.  Consequently,  large  numbers  of  gov¬ 
ernment  people  depart  in  hopes  of  better  pay  and  fewer  frustrations. 

3.2.3.  1  Red  Tape 

The  government  red  tape  involved  in  conducting  everyday  business 
(cost,  activity,  time,  travel  accounting,  reiterative  justification  for  slots, 
conformity  reporting,  etc.  )  significantly  reduces  the  amount  of  productive 
engineering  time.  The  actual  time  spent  complying  with  this  red  tape  is 
augmented  by  the  accompanying  effects  of  continual  interference  and 
frustration. 
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3.  2.  3.  2  Promotion 


Target  grade  limitations,  combined  with  the  government's  more 
rigid  CS  growth  structure/candidate  selection  process  gives  rise  to  having 
unqualified  (i.  e.  ,  inexperienced  in  software/ECS's)  personnel  managing 
and  performing  O&S  tasks.  The  frustration  of  not  being  promoted  when 
true  merits  dictate,  combined  with  the  futility  of  reporting  through  the 
resultant  structure,  serves  a  demoralizing  blow  to  the  aggressive  soft¬ 
ware  engineer/manager. 

3.  2.  3.  3  Responsibility/Authority 

Because  of  the  service  capacity  in  which  the  computer  resource 
branches  are  ordained,  their  role  is  sometimes  marked  with  responsi¬ 
bility  without  commensurate  authority.  Particularly  in  the  pre-PMRT 
domain  when  TDY  funds  and  support  personnel  are  scarce,  the  MME C 
software  engineer  must  negotiate  with  the  SPO,  user,  AFALD,  and  other 
ALC's  in  attempting  to  establish  a  software  O&S  posture,  often  without 
the  full  backing  of  the  SM. 

As  AFALD  is  the  AFLC  prime  mover  in  the  pre-PMRT  era,  the 
ALC  representative  must  assume  a  back  seat  role.  In  cases  wherein 
AFALD  is  not  quite  as  strong  as  it  should  be,  this  can  prove  to  be  a 
demoralizing  venture. 

3. 2. 3. 4  Professionalism 

To  ensure  accountability  to  the  multitude  of  agencies  and  activities 
created  to  ensure  that  government  employees  are  not  taking  advantage  of 
the  system,  rigid  and  sometimes  degrading  measures  are  taken  to  control 
such  things  as  working  hours,  TDY  benefits,  administrative  leave,  and 
comp  time. 

3. 2.  2.  5  Technical  Challenge 

As  a  result  of  manpower  shortages,  delayed  training,  etc.  ,  the 
junior  (or  untrained  senior)  engineer  finds  himself  in  the  unpleasant  situ¬ 
ation  of  having  to  make  vital  decisions  (or  provide  vital  inputs)  without  the 
benefit  of  technically  understanding  the  issues  at  hand.  On  the  other  hand, 
the  bright,  conscientious  engineers  are  not  satisfied  with  a  "paper  work" 
job  forced  upon  them  by  delays  in  equipment  deliveries.  Numerous 
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resignations  from  civil  service  give*  "lack  of  challenge"  as  the  reason. 

With  the  amount  and  quality  of  work  now  required  by  AFLC,  good  planning 
and  resource  utilization  can  alleviate  any  lack  of  challenge. 

3.3  RECOMMENDATIONS 

Many  of  th«  aforementioned  issues  are  not  peculiar  to  AFLC  but 
rather  common  with  those  confronting  other  government  agencies  and,  in 
cases,  industry  engaged  in  software  development  and  OkS.  Tempered  with 
the  recognition  that  these  issues  largely  represent  the  bow  wave  of  a 
rapidly  expanding  technology  and  that  such  issues  are  by  no  means  new 
to  USAF  management,  this  points  to  their  tenacious  nature.  The  alterna¬ 
tives  tendered  below,  together  with  other  DOD  and  USAF  efforts  currently 
underway  to  address  such  issues,  however,  offer  the  promise  of  eventual 
resolution. 

1.  Develop  within  guidance  provided  by  HQ  AFLC  (e.  g.  ,  via 

AFLCR  800-21.  AFLCR  400-XX) 

a.  Detailing  of  the  various  support,  concepts  and  alterna¬ 
tives,  and  accompanying  decision  rationale,  requisite 
in  arriving  at  an  optimum  approach  (i.  e.  ,  a  more 
detailed  version  of  the  logic  paths  sketched  for  the 
AFLC  Ci  LDT  in  AFLCR  400-XX).  Included  should  be 

a  clear  breakout  of  governmental  and  readiness  func¬ 
tions.  It  is  recommended  that  any  organic  staffing 
logic  used  be  based  upon  an  average  employee  tenure 
of  4  to  7  years  versus  the  1  5  to  20  years  usually  asso¬ 
ciated  with  government  employees. 

b.  Specific  guidance/ AF  LC  policy  regarding  the  consoli¬ 
dation  of  resources  (including  cross-training)  across 
AFC's  and  ECS's. 

c.  A  generic  breakout  of  functions  and  activities  required 
in  the  software  Ok-S  job  for  a  given  ECS  as  well  as  for 
a  multi- ECS  environment  (Reference  3-1  provides  the 
rudiments  for  such  a  breakout). 

d.  A  skill  level  index  accompanying  position  descriptions, 
and  manpower  quantity  algorithms  which  tracks  with 

1  a  through  lc. 

e.  A  step-by-step,  time-phased  trace  depicting  the  man¬ 
power  acquisition  (authorization)  process,  including  new 
starts  and  other  additive  elements,  as  well  as  a  respon- 
sibilitv  breakdown  between  HQ  AFLC  offices,  ALC 
offices,  .ind  MES  Detachments.  Other  manpower  exer¬ 
cises  which  are  conducted  but  not  related  to  the 
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authorization  process  should  be  discussed  for  informa¬ 
tion  purposes . 

f.  An  expansion  of  the  CRISP  content  to  include  contingency 
planning  for  ECR's  in  the  event  manpower,  funding, 
MCP's  inherent  in  the  primary  support  role  are  delayed 
or  denied. 

Conduct  a  study  to  evaluate  traditional  support  roles  and 
missions  of  the  various  AF  LC  organizations  (i.  e.  ,  AC, 

MMR  MMEC,  MMET  MA-T)  as  they  relate  to  computer 
resources,  including  the  matrix  management  concept  in  the 
ALC's.  The  result  of  this  study  should  be  a  work  breakdown 
structure  for  the  job  description  in  lb. 

Clarify  and  definitize  in  USAF-level  guidance  (e.  g.  ,  AFR 
800-14)  the  roles  and  missions  of  the  using  command  and 
support  command  insofar  as  software  O&S  is  concerned. 

The  guidance  should  be  well  keyed  to  the  concepts  and 
alternatives  developed  in  la. 

On  the  basis  of  the  WBS  developed  in  2,  provide  guidance 
to  the  ALC  for  organizational  structure  in  MMEC  organi¬ 
zation  and  definition  of  interface  functions  within  the  MMR, 
MA-T,  AC,  etc.  ,  organizations. 

Establish  through  channels  a  means  to  provide  sufficient 
pre-PMRT  manpower  and  funding  for  post-deployment 
posturing,  DT&E,  IOT& E  support,  etc. 

Establish  a  recruiting  activity  within  each  ALC,  thus  reduc¬ 
ing  the  engineering  role  in  this  regard  to  one  of  conducting 
technical  interview  and  deciding  among  candidates.  Make 
provisions  as  necessary  for  manpower  requirements  for 
activity  and  funds  for  TDY,  advertising,  etc. 

Replace  the  MES  Detachment  function  in  the  software  O&S 
manpower  authorization  loop  by  establishing  a  manpower 
screening  function  within  HQ  AFLC/LOEC  to  approve  ALC 
software  O&S  ECR  requirements. 

Take  steps  to  have  software  manpower  removed  from  the 
"additive"  category  and  placed  in  the  manpower  baseline 
with  other  O&M  functions. 

Take  action  through  HQ  USAF  to  establish  CRISP's  as  for¬ 
mal  intercommand  MOA's  and  formal  instruments  of  approval 
for  ECR's. 

Continue  attempts  to  establish  special  categories  and  high 
grade  authorizations  for  software  engineers  (via  the  Joint 
Civilian  Personnel  Management  Group  studying  recruitment, 
retention  and  utilization  of  engineers  and  the  Civil  Service 
Commission). 
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11.  Establish  Offices  of  Primary  Responsibility  (OPR's)  for 
ECS  software  O&S's  training  at  HQ  AFLC/LOEC  and  at 
each  ALC . 

12.  Develop  a  top  level  training  plan,  in  coordination  with  ATC, 
AFIT  etc.  ,  for  ECS  O&S  engineers  and  managers.  The 
plan  developed  in  1976  by  HQ  AFLC/LOEC  represented  a 
good  start  in  this  regard.  It  is  strongly  urged  that  a  one- 
year  to  18-month  formal  training  program  (such  as  currently 
conducted  for  flight  training,  maintenance  officer's  school, 
logistics  management  school,  etc.  )  be  developed  for  soft¬ 
ware  engineers  and  a  two-  to  four-week  course  for  software 
managers. 

13.  Establish  in  HQ  AFLC/  LOEC  a  special  position  (e.g., 

GS-14  or  GS-15)  for  an  expert  in  ECS  O&S  who  has  first¬ 
hand  experience  in  the  problems  confronted  by  ALC's. 

This  position,  which  might  be  rotational  in  nature,  should 
be  filled  from  the  ALC's.  The  chief  role  of  this  position 
would  be  to  advise  the  ALC's  of  their  problems  and  to  par¬ 
ticipate  in  the  HQ  decision  process. 

14.  Explore  more  effective  means  of  using  the  networks  avail¬ 
able  to  AFLC  for  training  and  cross-training  devices. 

15.  Within  the  WBS  developed  in  2,  consider  adding  additional 
administrative  positions  for  absorbing  many  of  the  less 
technical  functions  now  carried  out  by  the  software  engineers. 

16.  Encourage  rotation  of  key  personnel  across  ECS's  (and  even 
ALC's)  to  help  in  keeping  these  invaluable  resources  chal¬ 
lenged  as  well  as  to  accelerate  the  training  process  for  the 
more  junior  employees. 

17.  Establish  a  more  structured  communications  loop  between 
HQ  and  the  ALC's  through  in-house  status /problem  reviews. 


4.  MICROPROCESSORS  AND  FIRMWARE 

4.  1  BACKGROUND 

Microprocessors  and  firmware  have  begun  and  will  continue  to  have 
a  major  impact  on  AFLC  support  and  management  of  electronic  systems. 
Because  of  the  many  advantages  provided  by  microprocessors  and  firm¬ 
ware,  such  as  flexibility,  reliability,  economy,  and  variety,  proliferation 
of  devices  and  their  increased  use  appears  inevitable.  Mass  production 
techniques  have  reduced  the  size,  cost,  and  power  of  Large  Scale  Inte¬ 
grated  (LSI)  circuits  and  promise  to  usher  in  the  Very  Large  Scale  Inte¬ 
grated  (VLSI)  circuits  with  greater  gate  density,  more  gates  per  package, 
lower  cost  per  gate,  and  lower  speed-power  product.  While  this  evolu¬ 
tion  of  technology  appears  staggering  at  first  observation,  the  ultimate 
task  of  the  AFLC  avionics  engineer  (to  enhance/correct  mission- related 
logic  in  systems/subsystems)  has  not  changed.  Only  the  implementation 
methodology  and  tools  utilized  have  changed  in  some  cases.  Also,  the 
trend  in  resource  allocations  is  changing  to  the  point  that  hardware  costs 
are  a  less  significant  percentage  of  the  total  cost  of  system/subsystem 
development  and  subsequent  modifications.  The  technology  evolution  is 
more  manifest  in  the  greater  range  of  applications  that  are  now  practical 
to  implement  through  LSI  and  VLSI  technology.  The  objective  of  this  sec¬ 
tion  is  to  develop  the  rationale  for  a  comprehensive  support  posture  within 
AFLC  which  will  encompass  this  expanding  technology.  The  impact  of 
management  stems  from  the  requirement  to  plan,  budget,  and  staff  to  sup¬ 
port  the  unique  qualities  of  these  devices.  The  most  important  observa¬ 
tion  made  during  this  investigation  was  the  need  for  common  treatment  of 
microprocessors  and  firmware  by  AFSC  and  AFLC. 

4.2  DISCUSSION 

Microprocessors  and  firmware  have  accelerated  the  changing  role 
of  AFLC  by  providing  both  change  flexibility  to  previously  hardwired  cir¬ 
cuits  within  airborne  systems  and  a  means  to  accomplish  support  tasks 
that  previously  were  impossible  to  accomplish  or  were  accomplished 
manually.  The  speed  and  size  available  with  state-of-the-art  devices 
make  it  possible  to  provide  signal  processing  capabilities  that  lend  them¬ 
selves  to  real  time  applications  in  the  area  of  programmable  interfaces 
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and  switching  networks  within  support  facilities,  as  well  as  airborne 
inst  rumentation/ equipment .  The  costs  involved  with  this  technology  now 
make  it  economically  feasible  to  support  activities  previously  accomplished 
manually,  from  improving  automation  of  man-machine  interfaces  to  off-line 
text  editing.  The  rush  to  the  proverbial  computer- on- a- chip  concept  has 
tended  to  confuse  the  issue  of  computer  acquisition,  management,  and 
accounting.  The  requirements  for  these  devices  contradict  the  procedures 
established  under  the  AFR-300  series  regulations  dealing  with  automatic 
data  processing  equipment;  however,  they  possess  characteristics  of  com¬ 
puters  that  impose  a  support  concept  different  from  non- reprogrammable 
ci  rcuits. 

Technical  impacts  are  significant.  More  processing  capability  pro¬ 
vides  for  higher  data  rates,  which  in  turn  dictates  higher  speed  data  hand¬ 
ling  capabilities.  On  the  positive  side,  these  higher  processing  capabili¬ 
ties  provide  more  and  better  data  for  avionics  usage  or  engineering  analysis, 
assuming  that  the  capability  exists  to  assess  and  utilize  the  data.  Manage¬ 
ment  impacts  are  driven  by  the  technical  issues,  in  that  management  must 
assume  a  posture  responsive  to  these  newly- acqui red  support  requirements. 

Another  impact  on  management  is  the  management  data  that  will  be 
available  in  real  time.  For  example,  within  today's  technology  access  to 
a  data  net  containing  management  information  can  be  made  available  at 
the  manager's  desk,  in  real  time,  that  heretofore  was  passed  to  him  in 
monthly  reports.  While  such  capabilities  for  management  and  administra¬ 
tive  functions  are  now  considered  commonplace,  their  full  potential  has 
vet  to  be  realized. 

One  method  of  discussing  the  support  requirements,  and  thus  man¬ 
agement  considerations  for  microprocessors  and  firmware,  is  to  make  the 
distinction  between  standard  software  support  for  general  purpose  com¬ 
puters  and  the  attributes  of  microprocessors  and  firmware  that  make 
their  support  different.  These  differences  may  be  categorized  in  the 
following  general  topics: 

•  Definitions 

•  Configuration  management 

•  Support  tools 

4-2 


,,  r.  -  ~ 


•  Languages 

•  Logistics  considerations 

•  Data  requirements 
4.2.1  Definitions 

Because  of  the  wide  variety  and  diversity  of  devices  available  in  the 
marketplace  (currently  approaching  200)  and  the  multitude  of  applications 
employing  these  devices,  a  universally  accepted  standard  set  of  definitions 
does  not  exist,  or  rather,  there  are  several  sets  of  standard  definitions 
cited,  depending  on  the  author  being  read.  The  following  set  of  definitions 
and  alternatives  are  stated  in  the  ASP  Airborne  Systems  Software  Acqui¬ 
sition  Engineering  Guidebook  for  Microprocessors  and  Firmware: 

•  Mic coprocessors.  "One  or  more  Large  Scale  Integration 
(LSI)  devices  that,  when  interconnected,  perform  the  func¬ 
tion  of  a  Central  Processing  Unit  (CPU).  "  (AFR  800-14, 

Vol.  I/AFSC  Supplement  1,  8  August  1977,  Att,  1,  para¬ 
graph  14.2).  Large  scale  integration  is  defined  in  para¬ 
graph  14.  8  of  the  above  as  "complexity  greater  than  approxi¬ 
mately  1000  logic  gates."  This  is  preferable  to  MIL-STD- 
11DBK  217B  which  defines  it  as  100  gates  or  greater.  A 
current  draft  of  Electronic  Industries  Association  (EIA) 
definitions  describes  a  microprocessor  as  "a  single  inte¬ 
grated  circuit  which  determines  and  implements  at  least 

the  arithmetic  logic  unit,  control  function,  and  instruction- 
set  architecture  of  a  computer.  " 

•  Mic rocomputer.  "A  microprocessor  plus  other  components, 
such  as  memories,  clocks,  and  various  interface  devices 
that  collectively  operate  as  a  stored  program  computer.  " 

(op.  cit.  ,  paragraph  14.  3).  A  simpler  definition  is  a  com¬ 
puter  whose  CPU  is  a  microprocessor.  Microcomputers 
may  come  packaged  on  a  single  chip  or  set  of  chips,  and 
often  are  sold  as  a  preconfigured  card  or  set  of  cards. 

•  Fi  rmware.  The  term  firmware  is  used  for  two  different 
concepts  which  must  be  distinguished.  The  first  is,  "Com¬ 
puter  programs  and  computer  data  at  the  microprogram 
level."  (op.  cit.,  paragraph  14.5).  This  type  of  firmware 
is  concerned  primarily  with  computer  design  and  instruction 
set  definition  and  implementation.  It  is  not  within  the  pur¬ 
view  of  this  guidebook  and  will  not  be  considered  further. 

The  second  is,  "Any  level  of  executable  computer  programs 
and  computer  data  that  cannot  be  readily  modified  under 
program  control,  that  is,  read-only"  (Ibid.);  "Software 
that  resides  in  a  non-volatile  medium  which  is  read-only 

in  nature.  Firmware  is  completely  write-protected  when 


4-3 


functioning  in  its  operational  mode.  "  (AFR  122-10, 
27  November  1978,  Att.  1,  paragraph  20). 


The  following  set  of  definitions  has  been  recommended  as  changes  to 
AFR  800-14,  Vol.  I/AFSC  Sup  I  by  Dr.  R.  J.  Sylvester,  ASD/EN  in  his 
white  paper  on  AFSC  microprocessor  policy: 

•  Computer  equipment.  Devices  capable  of  accepting  or 
storing  computer  data,  executing  a  systematic  sequence 
of  operations  on  computer  data  or  producing  outputs. 

•  Instruction  set  architecture.  The  attributes  of  a  digital 
computer  as  seen  by  a  machine  language  programmer; 

i.  e.  ,  the  conceptual  structure  and  functional  behavior  of 
a  digital  computer  (at  the  machine  language  level)  as  dis¬ 
tinct  from  the  organization  of  data  flows,  logic  design, 
and  physical  implementation. 

•  Microprocessor.  A  single  or  small  set  of  integrated  cir¬ 
cuits  which  implement  at  least  the  arithmetic  logic  function, 
control  function,  and  instruction  set  architecture  of  a  digital 
computer. 

•  Mic  rocomputer.  Mic  roproces sor (s )  plus  the  necessary  sup¬ 
port  devices  (if  not  already  part  of  the  microprocessor) 
which  implement  a  digital  computer.  (NOTE:  A  computer- 
on-a-chip  is  considered  both  a  microprocessor  and  a 
microcomputer.  ) 

•  Firmware.  Any  level  of  computer  programs  and/or  com¬ 
puter  data  that  cannot  be  readily  modified  under  computer 
program  control;  that  is,  read-only.  The  definition  also 
applies  to  read-only  digital  data  that  may  be  used  by  elec¬ 
tronic  devices  other  than  digital  computers. 

•  Computer  data.  Basic  elements  of  information  used  by 
digital  computer  equipment  in  responding  to  a  computer 
program.  Data  operated  on,  produced  by,  or  otherwise 
used  by  a  computer  program. 

•  Integrated  circuit.  An  electronic  device,  commonly  called 
a  chip,  that  integrates  individual  electronic  elements  (i.  e.  , 
transistors,  diodes,  resistors,  and  capacitors)  onto  a  single 
solid-state  substrate. 


Large  scale  integration.  Any  integrated  circuit  chip  with  a 
complexity  greater  than  approximately  1,000  logic  gates. 

Embedded  computer.  A  computer  that  is  integral  to  a 
larger  system,  subsystem  or  component  from  a  design, 
procurement,  and/or  operations  perspective.  The  larger 
system  function  is  not  generally  data  processing. 
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•  Hardware  intensive  applications.  Those  embedded  com¬ 
puter  applications  in  which  the  function  is  fixed  and  hence 
the  computer  program  (after  development  and  test)  is  not 
expected  to  be  changed  for  the  lifetime  of  the  physical 
component  in  which  the  computer  is  embedded. 

The  latter  set  of  definitions  is  more  inclusive  in  scope  by  attempting 
to  provide  definitions  of  computer  equipment,  instruction  set  architecture, 
computer  data,  and  embedded  computer  that  encompasses  the  field  of 
microprocessors.  However,  the  white  paper  definition  for  microprocessor 
does  not  include  larger  aggregations  of  chips  such  as  in  bit-slice  applica¬ 
tions.  In  both  references,  AFSC  has  attempted  to  define  subsets  of  device 
applications  which  are  Hardware  Intensive,  Software  Intensive,  and  Firm¬ 
ware  Intensive  allowing  classification  based  on  logistic  support  require¬ 
ments  rather  than  commercial  device  configuration.  AFLC  has  a  set  of 
definitions  in  AFLCR  800-21,  Attachment  1,  which  differs  from  either  of 
these  slightly.  It  also  addresses  hardware  and  software  intensive  applica¬ 
tions.  While  it  is  recognized  that  the  support  required  is  heavily  depend¬ 
ent  on  application,  it  must  also  bo  recognized  that  this  classification  is 
somewhat  subjective  and  must  be  made  early  in  the  system/subsystem 
development  process  to  accurately  assess  the  support  requirements. 

That  is,  to  classify  the  application  accurately  requires  technological 
decisions  based  on  system  knowledge  and  operational  requirements.  This 
assessment  cannot  be  taken  lightly  and  must  be  accomplished  by  extremely 
knowledgeable  personnel.  Since  the  policies  and  methodology  used  by 
AFSC  in  dealing  with  microprocessors  and  firmware  will  have  a  major 
impact  on  the  AFLC  support  posture,  it  would  appear  to  be  a  tremendous 
advantage  to  have  a  mutually  agreed  upon  and  used  set  of  definitions  and 
criteria  from  which  to  work  so  that  transition  can  occur  with  as  little 
confusion  as  possible. 

4.2.2  Configuration  Management 

The  unique  properties  of  microprocessors  and  firmware  dictate 
unique  configuration  management  procedures  different  from  both  hardware 
and  software  yet  encompassing  techniques  from  both.  It  is  obvious  that 
a  baseline  must  be  established  and  configuration  and  status  accounting 
maintained;  however,  the  detailed  implementation  of  a  standardized  uni¬ 
versal  system  is  made  more  difficult  by  the  physical  and  electrical 
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j  properties  of  the  varied  devices.  For  example,  firmware  when  pro- 

I 

grammed  may  have  an  almost  unlimited  number  of  possible  configura¬ 
tions  which  are  machine  readable,  but  which  require  specialized  equip¬ 
ment.  Combine  this  with  the  fact  that  both  the  program  and  the  media 
embodying  the  program  must  be  controlled.  A  "reasonable"  example  of 
identification  for  configuration  control  extracted  from  requirements  of 
DI-A-3001  is  provided  in  the  ASD  microprocessors  and  firmware  guide¬ 
book  as: 

Media  and  Related  Documentation 

•  CPIN 

•  Version/distribution  date 

j  m  Chip  number-of-total 

•  Socket  number 

•  Additional  data  as  required  (e.  g.  ,  inventory  number, 
internal  check  sum) 

Kxlornal  Identification 

i 

•  Vendor  part  number 

•  Version  number 

•  •  Socket  number 

I 

Internal  Identification 

•  Same  as  media  and  external  identification 
t 

!  •  Additional,  if  required 

The  external/internal  identification  scheme  suggested  in  the  guide¬ 
book  is  presented  in  Figure  4-1,  with  the  internal  identification  encoded 
j  in  source  test  format  near  the  beginning  of  the  chip,  if  possible.  In  addi¬ 

tion  to  the  special  identification  requirements  stated  above,  the  program 
J  must  be  managed  as  a  system  element  as  dictated  by  AFR  800-14  under 

!  MIL-STD  procedures.  Data  and  documentation  requirements  are  cited  in 

another  paragraph  because  of  the  physical  characteristics  of  the  chips 
themselves  and  the  boards  on  which  they  reside.  Labeling  to  identify  the 
,  media  and  the  internal  configuration  of  chip  and/or  board  is  complicated. 
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A  standard  method  of  identification  and  labeling  for  the  chip,  board,  and 
black  box  is  needed. 


4.2.3  Support  Tools 

One  of  the  major  impacts  on  AFLC  perpetrated  by  the  evolution  of 
microprocessors  is  the  requirement  for  additional  tools  to  develop,  test, 
and  modify  logic  implemented  via  chip  technology.  These  tools  span  the 
range  from  universal  microprocessor  development  systems  commercially 
available  from  various  vendors  to  specially  designed  software  test  aids 
unique  to  one  particular  chip.  Paragraph  4.  2.  3.  1  is  a  discussion  of  com¬ 
monly  used  tools  extracted  from  the  ASD  microprocessors  and  firmware 
guidebook.  While  many  of  these  tools  are  commercially  available  and  may 
be  applicable  to  multiple  chips  and  uses,  normally  a  great  deal  of  engineer¬ 
ing  labor  is  required  to  develop  application  and  device/system-peculiar 
support  attributes.  Even  with  these  labor-intensive  efforts  considered, 
an  excellent  microprocessor  laboratory  facility  can  be  acquired  for  rela¬ 
tively  low  cost  due,  for  the  most  part,  to  the  inexpensive  nature  of  the 
hardware  involved. 

The  development  of  standard  support  facilities  at  the  five  ALC's 
and  ACMC  could  have  the  effect  of  bringing  some  commonality  to  this 
support  arena  and  pressure  the  acquisition  agencies  into  restraining  the 
proliferation  of  devices  more  to  those  for  which  a  support  capability  exists. 
While  there  are  implications  in  some  of  the  recent  documents  that  AFLC 
is  considering  the  acquisition  of  a  standard  microprocessor  support  facil¬ 
ity,  the  only  efforts  apparent  are  system/application- peculiar  acquisitions, 
along  with  the  planned  development  system  at  McClellan.  It  appears  that 
a  centralized  effort  to  procure  and  integrate  a  standard  growth-oriented 
laboratory  for  all  the  ALC's  is  needed  to  meet  current  and  future  needs. 

4.  2.  3.1  Tools  and  Techniques  for  Microprocessor  Development  and  Support 

Although  microprocessor  systems  are  conceptually  divided  into  hard¬ 
ware,  firmware,  and  software  subsystems,  functionally  they  operate  as  a 
digital  system.  Implementing  a  given  subsystem  in  firmware  or  software 
rather  than  hardware  buys  you  increased  flexibility  but  only  if  appropriate 
tools  exist  to  capitalize  on  it. 
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The  purpose  of  a  tool  is  to: 

•  Provide  visibility  into  system  operation 

•  Automate  repetitive  control  tasks 

•  Collect  a  d  reduce  data  on  system  behavior 


No  automated  tool  known  can  prove  program  correctness.  Hence 
the  best  tool  will  provide  controlled  exercise  of  the  microprocessor  with 
the  maximum  visibility,  speed,  and  ease  of  use,  and  collect  and  reduce 
the  most  behavioral  data  for  ultimate  human  analysis. 

4.2.3.  1.1  Types.  Tools  unique  to  microprocessors  and  fi rmwar e 
are  presented  below. 

•  In-Circuit  Emulator  (ICE).  A  device  which  is  substituted 
in  place  of  a  microprocessor  and  which  duplicates  its 
operation  both  logically  and  electrically.  Usually  operated 
in  a  master/slave  relationship  in  conjunction  with  an  MDS 
microprocessor  acting  as  master:  plugging  the  slave 
microprocessor  (ICE)  in  place  of  the  target  microprocessor 
extends  the  capabilities  of  a  MDR  to  those  of  powerful  Com¬ 
puter  Monitor  and  Control  (CMAC).  A  memory-mapping 
capability  allows  the  target  microprocessor  to  utilize  MDS 
memory  as  if  it  were  its  own.  In  addition  to  substituting 
for  the  target  microprocessor  and  interfacing  to  the  MDS, 
the  IC  E'  usually  contains  trace  buffers  and  other  diagnostic 
aids.  An  ICE  may  also  come  as  a  self-contained  system 
packaged  in  an  attache  case  for  field  use.  This  is  a  device 
that  is  unique  to  LSI  technology  and  has  almost  unlimited 
utility. 

•  Logic  analyzer.  A  device  for  monitoring  other  digital 
devices  on  the  logical  level.  Displays  timing  information 
and  logic  levels.  Displays  numerical  data  in  a  variety  of 
formats,  including  as  disassembled  machine  instructions. 

•  Memory  mapping.  Substituting  one  memory  for  another 
via  a  real  time  address  translation  map. 


Microcomputer  Development  System  (MDS)  or  Microcom¬ 
puter  Prototyping  System  (MPS).  A  microcomputer  con¬ 
figured  as  a  stand-alone  system  for  software/firmware 
development  and  support.  Besides  the  features  of  mini¬ 
computer  systems  (mass  memory,  operating  systems, 
CRT's),  it  has  the  capability  of  interfacing  with  a  PROM 
programmer  (or  other  firmware  configuration  tool),  and 
an  In-Circuit  Emulator  (ICE)  or  other  microprocessor  debug 


tool.  The  mass  memory  device  mav  consist  of  anything 
from  paper  tape  to  disc,  usually  floppy  disc  (diskettes). 
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Lack  of  capability  to  support  multiple  users  may  be  a 
problem. 

•  Microprocessor  analyzer.  Similar  in  capabilities  to  an 
ICE,  but  clipped  onto  the  microprocessor  leads  instead 
of  substituted  for  the  microprocessor. 

•  PROM  programmer.  A  tool  for  imprinting  (programming) 
and  reading  the  bit  patterns  of  Programmable  Read-Only 
Memory.  May  be  operated  remotely  by  an  MDS,  or  man¬ 
ually.  Can  also  be  used  to  verify  the  contents  of  PROM's. 

•  ROM  simulator.  A  writable  RAM  used  to  emulate  a  ROM 
to  enhance  firmware  debug  prior  to  burn-in.  May  be  pur¬ 
chased  separately  or  as  capability  in  an  ICE. 

•  Signature  analysis.  A  method  for  isolating  faults  to  the 
node  level  in  a  logical  circuit.  Requires  additional  cir¬ 
cuitry  built  into  the  system. 

•  T race  buffe r .  A  memory  for  the  storage  of  real  time 
microcomputer  bus  signals  for  use  in  logic  testing. 

Usually  runs  under  control  of  an  MDS  in  conjunction  with 
an  IC  E. 

•  Universal  development  system.  An  MDS  with  capability  of 
multiprocessor  support,  including  interface  with  multiple 
ICE's. 

4.  2.  3.  1.2  Use.  The  MDS  with  an  ICE,  logic  analyzer,  and  a  PROM 
programmer  is  currently  the  most  effective  combination  known  for  micro¬ 
processor  life  cycle  support.  The  Universal  Development  System  (UDS) 
has  the  further  attractive  capability  of  supporting,  with  appropriate  adapt¬ 
ers,  multiple  dissimilar  microprocessor  types.  Their  use  in  the  life 
cycle  is  briefly  described  as  follows.^ 


l 


^  Logic  analyzers  are  useful  for  hardware  debugging  throughout  this  cycle, 
especially  in  areas  of  timing,  and  parts  of  the  circuit  relatively  invisible 
to  the  microprocessor. 
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Development  Test  and  Evaluation  Phase 


A.  The  MDS  (or  UDS)  may  be  used  in  advance  of  hardware 

development  to  code  and  test  all  internal  microprocessor 
routines.^  The  use  of  the  ICE  allows  emulation  of  the 
stand  alone  microprocessor  and  symbolic  debug  of  the 
program.  No  firmware  memories  need  to  be  used  at 
this  stage,  as  the  MDS  RAM  will  emulate  them  through 
the  memory-mapping  feature. 

^  STAND  ALONE  DEVELOPMENT  OF  SOFTWARE 


MDS  OR  UDS 


B.  Effective  use  may  also  be  made  of  a  MDS/ICE  to  debug 
microprocessor  hardware  by  executing  software  diag¬ 
nostics  and  I/O  drivers. 


^  DEBUG  OF  TARGET  SYSTEM  HARDWARE 

MDS  OR  UDS  TARGET  SYSTEM 


C.  Then  the  software  may  be  exercised  under  MDS  control 
using  the  ICE  in  the  final  circuit  environment  of  the 
microprocessor.  At  this  point  the  MDS  RAM  (using 
the*  memo ry- mapping  feature  of  the  ICE)  is  still  used 
to  emulate  the  target  PROM  or  ROM. 


^  DEBUG  OF  TARGET  SYSTEM  EMULATED  FIRMWARE 
MDS  OR  UDS  TARGET  SYSTEM 


^Cross-compilers  and  assemblers  mav  also  be  used  at  this  stage. 
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D.  Next,  the  PROM  may  be  imprinted  using  the  PROM 
Programmer  under  control  of  the  MDS. 


^  BURN-IN  OF  FIRMWARE 


E.  Now  the  PROM's  may  be  plugged  into  the  target  system, 
and  the  code  executed  using  the  ICE  under  control  of 
the  MDS. 


^  DEBUG  OF  TARGET  SYSTEM  WITH  FIRMWARE  IN  PLACE 
MDS  OR  UDS  TARGET  SYSTEM 


F.  Finally,  the  ICE  may  be  removed,  the  microprocessor 
put  in  its  place,  and  the  system  operated  alone.  Here 
there  may  still  be  firmware  s elf- i nst rumentation  and 
other  controls  and  displays  built  into  the  target  system. 


^  STAND  ALONE  OPERATION  OF  TARGET  SYSTEM 
TARGET  SYSTEM 


TARGET 

... 

LOGIC 

MICRO 

TARGET 

ANALYZER 

PROM 
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O&M  Phase 

G.  The  ICE  can  be  taken  to  the  field  to  assist  in  mainte¬ 
nance  of  the  microprocessor.  The  MDS  with  the  PROM 
Programmer  is  used  in  stand-by  mode  for  possible 
program  patches. 


^  FIELD  MAINTENANCE 


4.2.4  Languages 

The  trend  in  AFSC  policy  is  to  require  that  for  non-hardware  inten¬ 
sive  applications,  an  Air  Force  approved  High  Order  Language  (HOL)  be 
selected  or  a  waiver  thereof  be  obtained.  This  is  certainly  a  step  forward, 
but  it  has  some  drawbacks.  First,  the  process  of  determination  of 
hardware/software/firmware  intensive  application  is  best  determined  by 
an  extensive  trade  study  based  on  change  intensity  by  qualified  personnel. 
The  fear  is  that  this  may  not  happen  for  a  number  of  reasons,  i.  e.  ,  the 
lack  of  qualified  experts  to  determine  this  change  rate  (there  is  consid¬ 
erable  difference  of  opinion  among  the  experts  as  to  change  frequency  to 
be  expected  for  a  particular  application).  Also,  front  end  costs  and  sched¬ 
ules  are  among  the  primary  motivating  factors  for  seeking  waivers. 
Another  concern  is  the  differences  in  Air  Force  approved  languages  and 
those  commonly  used  in  commercial  applications.  Section  4.2.4.  1  is 
from  an  ASD  guidebook  desc  ri  ptions /tradeoff  s  section  for  microprocessor 
HOL's. 

For  those  applications  which  AFL.C  intends  to  support  organically,  a 
strong  emphasis  should  be  placed  on  acquiring  devices  with  HOL  support 
during  the  acquisition  process.  This  can  be  accomplished  via  the  Com¬ 
puter  Resources  Integrated  Support  Plan  (CRISP)  and  through  attendance 
and  active  participation  in  design  reviews  by  AF LC  agencies.  Other 
emphasis  has  been  in  the  direction  of  an  Ada  HOL  or  subset  thereof  for 
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microprocessor  application.  With  the  advent  of  forced  compliance  with 
Ada  as  a  standard,  this  step  will  probably  become  a  necessity.  A  subset 
will  probably  come  about  by  marketplace  adoption,  rather  than  Govern¬ 
ment  di  rection. 

4.2.4.  1  Key  Tradeoffs  Between  Popular  Microprocessor  HOL's 

The  following  discusses  popular  microprocessor  higher  order 
languages  and  key  tradeoffs  between  each: 

•  FORTRAN.  Basically  a  scientifically  oriented  floating¬ 
point  language,  it  requires  a  large  memory  overhead  in 
system  routines  to  perform  mathematical  functions  and 
I/O.  As  such,  it  is  very  inefficient  on  machines  with 
small  word  width,  small  memories,  and  fixed-point  arith¬ 
metic  units.  For  processors  that  can  support  it,  it  is  one 
of  the  easiest  languages  to  optimize  for  speed.  Supports 
modularity  and  can  be  made  to  support  structured  pro¬ 
gramming  (e.g.  ,  IFTRAN,  etc.).  FORTRAN  is  included 
in  the  AFR  300-  10  list  of  approved  HOL's. 

•  JOVIAL  J73.  A  block-structured  language  similar  to 
PL/1  and  PASCAL.  Compilers  are  currently  being  devel¬ 
oped  for  several  microprocessors.  (Also  an  AF  approved 
language. ) 

•  BASIC.  This  is  (usually)  an  interpretive  language,  mean¬ 
ing  that  each  statement  is  compiled  as  it  is  keyed  in,  com¬ 
pilation  usually  consisting  of  compression  of  the  statement. 
Numbers  are  held  as  strings  of  binary-coded  decimal  (BCD) 
characters.  This  is  one  of  the  most  flexible  languages 
available,  but  one  of  the  slowest  to  execute.  This  language 
does  not  support  structured  programming,  modularity,  or 
fixed-point  arithmetic. 

•  PL/M.^  This  PL/ 1-like  language,  designed  to  support 
microprocessors,  has  data  types  natural  to  them.  Com¬ 
paratively  little  support  is  available  with  this  language 
because  of  its  immaturity.  Supports  block  structure  mod¬ 
ularity.  structured  programming,  and  fixed-point  arithmetic 

•  PASCA  L.  Another  block-structured  language  with  wide 
university  support.  Includes  the  capability  to  define  new 
data  types.  Supports  modularity,  structured  programming, 


^Use  of  these  languages  for  deliverable  code  requires  the  appropriate 


•  Ada.  The  proposed  DOD  standard.  This  language  was 
designed  with  embedded  applications  in  mind;  however, 

the  full  language  may  be  too  much  for  some  microcomputers 
to  handle.  A  reasonable  subset  will  have  to  be  defined  in 
the  light  of  unique  microprocessor  characteristics  and 
constraints. 

4.  2.  5  Logistics  Considerations 

There  are  a  variety  of  wrinkles  introduced  into  the  overall  logistics 
management  environment  by  the  evolution  of  microprocessors  and  firm¬ 
ware.  While  many  of  these  concepts  are  not  new  to  AFI.C,  the  new  twist 
is  that  both  hardware  and  software  considerations  must  be  accomplished, 
and  expanded  in  some  cases.  The  following  is  a  diverse  sampling  of  some 
of  the  embedded  computer  resource  considerations,  '’’his  list  is  by  no 
means  exhaustive,  but  rather  tries  to  place  emphasis  on  the  wide  range 
of  considerations  which  AFLC  must  entertain.  Further  management  con¬ 
siderations  are  shown  in  Table  4-1. 

•  Engineering  specialties.  The  trend  will  be  away  from 
staffing  with  the  traditional  ha rdwa re / softwa re  split  in 
specialization  toward  the  electrical  engineering  discipline 
with  digital  skills.  This  is  not  to  say  that  specialization 
will  not  still  exist,  only  that  there  will  be  a  shift  in  that 
direction.  Since  the  trend  in  Al.FC  has  always  been  toward 
the  EE  discipline,  the  impact  on  AFLC  will  probably  be 
less  than  on  industry. 

•  Farts  distribution.  The  implementation  of  computer  soft¬ 
ware  in  firmware  dictates  that  not  only  does  the  program 
require  distribution,  but  the  ROM  or  PROM  must  also  be 
available  for  field  implementation.  Of  course  this  form  of 
implementation  requires  additional  intermediate  and  flight 
line  equipment  such  a<=  PROM  burners  and  verifiers.  Pre¬ 
programmed  chips  must  be  physically  dispatched  rather 
than  via  communication  links. 


•  Parts  reliability  and  shelf  life.  Although  firmware  is  typi¬ 
cally  considered  very  reliable,  little  is  known  about  the 
impact  that  greater  gate  densities  will  have  on  MTBF  and 
shelf  life.  There  is  considerable  controversy  concerning 
shelf  life  and  environmental  conditions  for  non-military 
standard  microprocessors.  The  most  advisable  route  is 
to  insist  on  QP1,  microprocessors  in  all  applications, 
where  possible,  and  provide  a  cool,  dry,  environment  for 
storage. 


•  Market  share.  Because  the  Government  is  a  relatively  low 
volume  consumer  of  microcircuit  devices,  they  do  not 
"drive"  the  development  of  commercial  items.  This  leads 
to  several  problems  for  management.  Because  the  market 
is  predominantly  commercial,  vendors  do  not  push  as  hard 
for  military  qualification  of  their  products.  Support  sys¬ 
tems  are  more  directed  to  commercial  applications.  While 
these  systems  are  relatively  inexpensive,  they  are  normally 
not  tailored  to  scientific/military  applications  and  require 
tool  development  prior  to  their  use. 

•  Sparing.  The  fact  that  firmware  devices  require  not  only 
replacement  due  to  failure,  but  also  due  to  changing  of 
mission  or  system  logic  has  caused  considerable  problems 
in  logistics  planning.  To  adequately  plan  for  replacement 
parts  several  unfamiliar  considerations  must  be  under¬ 
stood  by  the  logistics  manager.  These  range  from  the 
expected  change  rate  and  degree  to  the  number  of  instruc¬ 
tions  and  memory  margin  per  chip.  These  considerations 
are  normally  out  of  the  purview  of  anyone  except  the  design 
and  systems  engineers  and  are  not  available  to  the  logistics 
planner.  It  is  imperative  that  data  on  these  technical  con¬ 
siderations  be  made^  part  of  the  support  planning. 

•  Maintainabilit/T^^ecause  of  the  reprogrammability  of  micro¬ 
processors  and  firmware  there  is  additional  emphasis  on 
making  these  parts  easily  accessible  for  change.  In  the 
case  of  chips  that  are  reprogrammable  under  program 
control  or  via  special  equipment/circuits,  these  too  should 
be  accessible  through  their  particular  medium. 

•  Parts  availability.  Because  of  the  volatile  chip  market, 
special  emphasis  must  be  placed  on  availability  and  sources 
of  replacement  cnips.  Here  the  best  insurance  is  the  main¬ 
tenance  of  contractual  and  other  commitments  of  avail¬ 
ability  with  vendors  and  the  use  of  QPL  parts. 

4.  2.  6  Data  Requirements 


Data  requirements  such  as  Part  I  and  Part  II  Specs  for  Computer 
Program  Configured  Items  (CPCI's)  are  adequately  covered  in  AFR  800-14 
and  AF LC  Supp.  1  thereto.  These  aspects  of  documentation  will  not  be 
covered  here.  Only  those  extensions  to  these  requirements  which  are 
additionally  needed  in  the  case  of  microprocessors  and  firmware  will  be 
addressed.  The  AFSC  trend  towards  identifying  digital  systems  as 
hardware/software/firmware  intensive  according  to  change  rate  is  cer¬ 
tainly  practical  to  reduce  the  delivered  documentation  requirements;  how¬ 
ever  AFLC  policies  and  procedures  must  be  in  total  consonance  with  this 


concept  for  life  cycle  support  problems  to  be  avoided.  An  error  in  judge¬ 
ment  in  establishing  the  incorrect  category  for  a  digital  system  will  have 
serious  long  term  economic  and  support  impacts.  The  point  is  that  no 
common  agreement  exists  between  AFSC  and  AFLC  on  this  issue.  The 
ASD/EN  position  is  that  no  new  firmware  Data  Item  Description  (DID)  is 
required,  only  that  existing  software  and  hardware  DID's  may  be  modi¬ 
fied  to  embody  firmware.  While  this  is  certainly  a  valid  assertion,  it 
does  not  appear  to  be  a  consensus.  There  should  be  a  positive  agreement 
with  AFSC  on  data  requirements.  Paragraph  4.  2.  6.  1  is  an  ASD- suggested 
list  of  system  design  aspects  which  documentation  should  cover,  and  another 
list  of  questions  which  documentation  should  answer  about  microprocessors. 

4.  2.  6.  1  System  Design  Aspects  Covered  By  Documentation 

•  Hardware  design 

1.  Circuit  diagrams 

2.  Clock  and  timing  data 

3.  Memory  design 

a.  Type 

b.  Physical  characteristics  (including  access  times) 

c.  Logical  characteristics  (including  word  length, 
number  of  words,  error  detection  and  correction) 

4.  I/O  design 

a.  Physical  characteristics  (bus  design,  timing,  cur¬ 
rent  and  voltage  levels) 

a  Logical  cha racteristics  (path  widths,  program 
addres  sability) 

5.  Hardware/software  interface 

•  Software  design 

6.  a.  Algorithms 

b.  Logic  flow 

c.  Source  listing 
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d.  Object  listing 


e.  PROM  programmer  input  listing 
7.  Design  tools 

a.  Support  software 

b.  Development  systems 

c.  Test  and  diagnostic  tools 

Microprocessors  typically  have  complex  memory  structures  for 
which  complete  documentation  is  essential.  Some  things  to  investigate 
are 


•  Physical  address  space.  What  types  of  chips  implement 
which  addresses,  what  are  their  access  characteristics? 

For  example,  read  only  or  read  write. 

•  Logical  address  space.  What  addresses  are  available, 
what  is  the  behavior  of  each  memory  location,  is  there 
any  memory-mapped  I/O,  are  there  any  "holes"  in  the 
address  space? 

•  Anomalous  behavior.  What  is  access  behavior  at  unused 
addresses,  what  side  effects,  undefined  conditions,  etc.  , 
are  there?  Can  two  or  more  processors  access  the  same 
memory?  What  about  interlock  protection? 

•  Unprogrammed  state  of  the  firmware  device.  All  l's  or 
all  0's? 

•  Patches.  Can  firmware  be  overwritten  or  just  programmed 
once?  Can  it  be  erased  and  reprogrammed?  Are  firmware 
components  soldered  in  place  or  in  sockets  for  easy  removal? 

•  Firmware  identification  procedures.  External  (ink  stamp, 
tape,  tag),  internal  (electrically  readable). 

•  Step-by-step  procedure.  Includes  all  operator  commands 
and  actions,  to  generate  firmware,  erase,  and  reprogram. 

4.3  RECOMMENDATIONS 

•  Formulate  a  joint  AFSC/AFLC  regulation  concerning  micro¬ 
processor  and  firmware  definitions,  concept  of  operations, 
configuration  management  practices,  policies,  and  proce¬ 
dures.  This  should  include  policies  on  HOL's  and  data 
requirements  and  the  need  for  firmware  DID's. 
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•  Develop  and  install  a  standard,  well- equipped,  growth- 
oriented  microprocessor  laboratory  at  each  of  the  five 
ALC's. 

•  Provide  support  for  the  development  of  an  Ada  language 
for  microprocessors. 

•  Provide  guidance  for  the  incorporation  of  microprocessor 
and  firmware  implications  into  the  logistics  planning 
process. 

•  Insist  that  AFSC  provide  data  on  microprocessors  and 
firmware,  sparing  requirements,  storage  environments, 
shelf  life,  and  parts  agreements. 

•  Establish  a  joint  AFSC/AFLC/ Industry  study  group  to 
standardize  identification  and  labeling  of  programmed 
and  programmable  devices. 
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5.  AFR  800  VERSUS  AFR  300  SERIES  ACQUISITION/SUPPORT 


5.  1  BACKGROUND 

Considerable  confusion  exists  with  regard  to  the  acquisition  of  com¬ 
puters  to  provide  for  ECS  support.  This  confusion  was  apparently  intro¬ 
duced  by  the  long  standing  policy  that  all  ADPE  (which  is  interpreted  to 
include  practically  all  computers)  was  managed  by  AC  under  the  300  series 
of  Air  Force  regulations.  With  the  release  of  AFR  800-14  in  September 
of  1975,  there  was  apparent  conflict  in  interpretation  between  this  regula¬ 
tion  and  AFR  300-2  in  that  ADP  resources  in  combat  weapon  systems  and 
special  designed  equipment  were  excluded  from  AFR  300-2  policy.  The 
ADP  single  manager  concept  remained  in  effect  under  AFR  800-14  and 
therein  additional  confusion  prevails;  i.  e.  ,  what  is  the  role  of  the  ADP 
single  manager?  Since  AFR  300-2  recognizes  the  existence  of  Air  Force 
computer  resources  to  be  managed  under  AFR  800-14,  the  major  problem 
is  the  extent  to  which  AFR  800-14  applies  to  dedicated  ECS  computers  and 
the  approval  authority  vested  in  the  ADP  single  manager.  This  review 
and  approval  authority  is  perceived  by  AFLC  ECS  managers  as  resulting 
in  AC  approval  of  MM  engineering  actions;  i.  e.  .  the  AC  ADP  single  man¬ 
ager  has  the  authority  to  influence  MM  actions  without  commensurate 
responsibility  to  accomplish  the  mission  assigned  MM. 

It  must  be  stated,  however,  that  this  problem  is  not  unique  to  the 
ALC's,  AFLC,  or  even  the  Aii  v^ce.  The  requirement  for  separate 
approval  and  procurement  paths  for  weapon  system  and/or  support  sys¬ 
tem  computers  and  other  system  components  appears  to  exist  for  all 
services.  In  addition,  because  of  the  varied  interpretations  placed  on 
the  available  guidance  at  the  DOD  and  service  levels,  this  guidance 
becomes  confusing  and  contradictory.  The  overriding  reason  for  this 
confusion  is  typically  blamed  on  the  implications  of  PL  89-306  (Brooks 
Bill);  however,  it  appears  that  most  of  the  problems  are  caused  by  imple¬ 
menting  regulations  and  the  interpretation  thereof,  rather  than  the  law 
itself.  It  is  commonly  agreed  that  PL  89-306  is  general  in  nature,  impos¬ 
ing  economical  and  efficient  procurement  of  automated  data  processing 
equipment  without  providing  ?  specific  definition  for  ADPE.  Since  the 
problems  facing  the  ALC-ECS  manager  appear  to  emanate  from  the  DOD 
level,  it  would  be  foolhardy  to  try  to  solve  them  at  a  lower  level.  While 


it  is  also  commonly  agreed  that  the  revolution  of  computer  technology  has 
substantially  changed  the  very  circumstances  which  prompted  the  Brooks 
Bill,  it  is  not  within  the  purview  of  this  paper  to  suggest  its  repeal,  even 
if  it  appears  long  overdue.  Because  this  paper  is  not  concerned  with  the 
problems  associated  with  major  weapons  system  acquisition,  but  rather 
with  the  concerns  of  the  ALC  manager  charged  with  engineering  support 
for  ECS,  the  paper  will  emphasize  the  development  and  operation  of  sup¬ 
port  facilities;  however,  the  problems  are  similar  for  acquisition  managers. 

5.2  DISCUSSION 

The  interpretation  leading  to  the  method  of  procurement  directly 
affects  the  time  required  to  have  an  operating  support  facility  on  line. 

The  PAR/DAR  process  is  generally  expected  to  require  three  years  for 
the  entire  approval  cycle,  while  normal  local  procurement  takes  on  the 
order  of  months  for  the  completion  of  the  approval  cycle.  The  procure¬ 
ment  process  and  support  system  (AISF)  development  time  must  be  added 
to  the  approval  cycle  before  a  system  is  ready  for  support.  This  timeline 
could  very  probably  provide  a  system  that  is  obsolete  before  it  is 
operational. 

Another  disadvantage  of  AFR  300  acquisition  is  the  impact  of  split 
procurement  (AFR  300  for  processor  and  peripherals  /  AFR  800  for  other 
AISF  elements)  which  must  play  together  to  satisfy  an  equipment  IOC.  In 
this  case,  the  AFR  300  acquisition  is  practically  always  the  pacing  factor 
when  equipment  is  acquired  through  the  DAR  process;  then  all  upgrades  or 
maintenance  activities  to  software  and  hardware  are  hobbled  by  the  DAR 
process,  extending  the  time  for  any  modification.  These  delays  are  not 
conducive  to  mission  responsiveness.  This  also  makes  more  difficult  the 
process  of  contracting  for  engineering  services  when  organic  resources 
are  not  available.  This  is  brought  about  by  a  basic  philosophical  difference 
in  management  approach  between  AFR  300  and  AFR  800  series  regulations 
(e.  g.  ,  doing  the  job  to  the  degree  that  a  normally  fixed  set  of  resources 
can  accomplish  versus  getting  the  job  done  to  a  defined  level,  drawing 
upon  whatever  resources  can  be  mustered). 
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Procurements  appear  to  be  driven  towards  AFR  300  or  a  nonre- 
solved  status  because  of  a  lack  of  understanding  of  the  role  of  the  ADP 
single  manager.  This  situation  is  further  complicated  by  the  fact  that 
the  AFLC  Computer  Resources  Review  Group  (CRRG)  is  chaired  by  a 
designated  representative  of  the  Command  ADP  Program  single  manager. 
This  is  perceived  in  the  field,  and  is  apparently  true,  as  signalling 
increased  involvement  by  ACD  in  embedded  computer  matters. 

While  the  issue  is  confused  at  the  lower  ALC  working  level,  periodic 
directives  and  interpretations  in  the  name  of  implementation  of  PL  89-306 
tend  to  foster  an  unsettled  atmosphere  and  uncertainty  at  all  levels  con¬ 
tributing  to  the  status  quo.  Recent  perturbations  which  had  the  most 
impact  were  the  proposed  DODD  7950.  1,  "Automatic  Data  Processing 
Resources  Selection  and  Management"  which  was  vague  in  its  exclusion 
clause  which  states  in  part,  "when  items  of  ADP  equipment  (and  software 
developed  therefor)  are  specially  designed  (not  configured)  and/or  when 
physicallv  incorporated  as  a  part  of  a  tactical,  weapon,  or  space  system 
or  manufactured  for  the  Government  under  a  development  contract  —  unless 
such  resources  become  excess  to  the  needs  of  the  DOD  component." 

While  this  description  is  open  to  interpretation,  it  does  not  appear  to 
encompass  many  ECS  categories  in  the  support  area;  e.  g.  ,  simulation 
host  computers,  computers  embedded  in  automatic  test  equipment,  engi¬ 
neering  data  reduction  and  analysis  facilities,  and  many  others.  The 
impact  of  this  proposed  directive  has  been  discussed  and  courses  of  action 
proposed  within  AFLC  and  the  JLC's;  however,  concern  has  been  expressed 
by  AFLC  staff  personnel  over  the  interpretation  taken  by  "watchdog" 
agencies  such  as  GAO,  GSA,  IG,  etc.  Another  detrimental  effort  was 
the  GSA  proposed  reclassification  of  ECS  computers  into  FSG  70.  While 
the  JLC's  and  the  Deputy  Under  Secretary  of  Defense  Research  and  Engi¬ 
neering  for  acquisition  policy  has  taken  vigorous  exception  to  the  reclassi¬ 
fication  effort,  the  matter  is  yet  to  be  resolved. 

Several  positive  actions  have  recently  taken  place  which  provide 
some  cause  for  optimism  in  this  area.  Most  of  the  progress  to  date 
stems  from  JLC  concerns/efforts  and  some  support  from  the  Office  of 
the  Deputy  Under  Secretary  of  Defense  Research  and  Engineering.  These 
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positive  actions  began  with  the  submission  of  proposed  changes  to  DODD 
5000.29  by  the  JLC's.  The  primary  purpose  of  these  proposed  changes 
would  be  to  clearly  define  embedded  computer  resources  as  including 
commercial  computers  used  in  defense  systems  or  embedded  in  equip¬ 
ment  which  is  used  in  defense  systems.  The  change  further  clarifies  the 
definition  of  "embedded"  to  include  any  computer  resource  which  is  inte¬ 
gral  to  the  operational  system  or  a  supporting  subsystem.  That  is,  com¬ 
puters  would  be  classified  as  embedded  based  on  configuration  as  well  as 
design.  This  proposed  change  was  considered  by  the  Executive  Board  of 
the  Management  Steering  Committee  for  Embedded  Computer  Resources 
and  representatives  of  the  ADP  Policy  Committee,  OASD(C)DDA.  Several 
conclusions  were  reached  at  the  initial  meeting: 

•  JLC  concerns  over  duplicate  approval  and  acquisition  chan¬ 
nels  for  weapons  systems  computer  resources  and  other 
weapons  systems  components  were  appropriate. 

•  The  technical  and  management  environment  has  changed 
radically  since  computers  became  an  item  of  special 
(legislative)  management  interest. 

•  End-item  exceptions  (to  ADPE  acquisition  policy)  should 
be  maintained  for  embedded  computers  regardless  of  ori¬ 
gin,  whether  obtained  commercially  off  the  shelf,  or 
specially  designed. 

•  A  full-time  working  group  should  convene  to  analyze  the 
recommendations  of  the  JLC. 

The  above  conclusions  and  the  establishment  of  the  ad  hoc  working 
group  on  embedded  computer  resource  acquisition  policy  are  encouraging; 
however,  it  is  now  even  more  important  that  AFLC  keep  the  momentum 
going  by  pressing  for  the  adoption  of  the  JLC  proposed  revisions  to  DODD 
5000.29.  Another  positive  aspect  of  the  JLC  initiatives  in  this  area  is 
that  they  do  not  advocate  circumventing  the  intentions  of  PL  89-306,  but 
rather  aim  to  ensure  that  the  intent  of  that  law  is  provided  through  the 
acquisition  review  process  established  by  DODD  5000.  2  (the  Defense  Sys¬ 
tems  Acquisition  Review  Council,  DSARC)  for  major  systems.  The  pro¬ 
posed  revision  further  provides  that  DOD  components  incorporate  pro¬ 
visions  in  their  review  process  to  ensure  that  cost-effective  procurement 
is  met.  This  would  closely  align  the  acquisition  of  system- related  computer 


resources  to  the  system  acquisition  process.  It  also  provides  that  these 
embedded  computer  resources  may  be  procured  without  a  delegation  of 
procurement  authority  from  GSA. 

The  JLC  PL  89-306  policy  application  subgroup  of  the  joint  policy 
coordinating  group  on  computer  resource  management  recently  concluded 
a  study  on  the  impact  of  the  law  on  defense  system  acquisition.  While  the 
findings  were  directed  at  the  acquisition  of  major  weapons  system  computer 
components,  they  could  just  as  well  have  been  made  concerning  the  acqui¬ 
sition  of  support  systems.  The  findings  of  that  study  were  that,  within  the 
context  of  the  Brooks  Bill  and  in  conformance  with  GSA  rules,  redundant 
approval  and  acquisition  channels  could  be  eliminated.  This  finding  led 
to  the  JLC  actions  in  proposing  DODD  5000.  29  revisions.  The  approval 
of  those  changes  will  have  a  most  positive  effect  on  ECS  support;  however, 
the  implementation  must  provide  clear  and  unambiguous  guidance  in  sup¬ 
port  of  these  changes. 

5.3  RECOMMENDATIONS 

This  acquisition  issue  is  currently  being  worked  by  the  Joint  Logistics 
Commanders;  therefore,  no  alternatives  are  suggested  other  than  to  con¬ 
tinue  support  of  the  JLC  initiatives  toward  adoption  of  the  proposed  changes 
to  DODD  5000.  29,  which  follow. 

1.  The  changes  to  DOD  Directive  5000.29  recommended  herein 
will  ensure  that  embedded  computer  resources  for  Defense 
systems  are  managed  consistently  and  in  accordance  with 

P.  L.  89-306  (Brooks  Bill)  and  Title  10  U.  S.  Code  which 
govern  systems  acquisitions.  In  addition,  these  changes 
will  set  policy  standards  governing  computer  resource 
acquisition  for  all  DOD  components  and  greatly  simplify 
procedures  for  program/project  managers.  Guidelines, 
similar  to  the  rationale  provided  below,  should  accompany 
the  changed  directive  in  order  to  clarify  interpretation  of 
its  provisions. 

2.  The  following  changes  are  proposed: 

a.  Change  paragraph  II.  B  to  read  as  follows: 

"Its  provisions  encompass  major  programs  of  Defense 
systems  acquisition,  as  designated  by  the  Secretary  of 
Defense  (described  in  Section  D  of  DOD  Directive 
50000,  1,  reference  (a)).  In  addition,  it  provides 


principles  to  be  applied  in  the  acquisition  of  Defense 
systems  that  do  not  fall  within  the  'major  acquisition 
category.  '  Included  are  all  computer  resources, 
including  general  purpose,  commercially  available 
computer  resources  which  are  embedded  in  Defense 
systems  or  embedded  in  equipment  which  is  used  in 
Defense  systems.  The  primary  purpose  of  such 
equipment  would  not  be  ADP  but  some  other  function 
such  as  automatic  test,  fire-control,  antenna  switch¬ 
ing  or  radio  transmission.  The  Decision  Authority 
who  has  cognizance  of  the  system  or  equipment  shall 
determine  if  the  said  system  or  equipment  is  an 
embedded  Defense  application  and  hence  falls  under 
the  provisions  of  this  directive.  " 

Rationale:  This  paragraph  spells  out  that  computer 
resources  included  under  the  provisions  of  this  direc¬ 
tive  are  those  which  are  embedded  in  Defense  systems 
or  in  equipment  used  in  such  systems.  General  pur¬ 
pose,  commercially  available  computer  systems  are 
specifically  stated  to  be  covered  because  they  have 
been  the  major  problem  in  this  area.  Under  the  pre¬ 
vious  version  of  the  Directive,  use  of  commercial 
components  was  discouraged  by  the  need  to  process 
requests  through  multiple  layers  of  DOD  activities 
specializing  in  acquisition  of  ADPE  for  business  type 
uses.  This  intermediate  DOD  layer  also  makes  it 
difficult  to  interface  with  GSA  to  get  exemptions  for 
Defense  type  applications.  The  time  delays  caused  by 
this  processing  encourages  Defense  system  managers 
to  choose  specially  designed  computer  resources  even 
though  standard  commercial  assets  may  be  cheaper  or 
more  reliable.  It  is  recognized  that  some  acquisitions 
will  be  ambiguous  and  cannot  be  readily  categorized 
as  a  Defense  or  non-Defense  application.  Examples 
of  such  applications  could  include  training  and  other 
such  subsystems  which  directly  support  one  or  more 
operational  systems.  This  paragraph  explicitly  states 
that  the  cognizant  Decision  Authority  for  the  system 
will  make  the  determination  for  Defense  applicability 
in  the  case  of  ambiguous  applications. 

Change  paragraph  II.  C  to  read  as  follows: 

"C.  Excluded  from  the  provisions  of  this  Directive 
are  non-Defense  Automatic  Data  Processing  Systems 
and  Automated  Information  Systems  assets  as  defined 
and  administered  under  OMB  Circular  A-71  and  DOD 
Directives  4105.55,  4160.19,  5100.40,  7920.  1  and 
7920.  3  (references  (b),  (c),  (d),  (e),  (n)  and  (o)). 
Examples  of  excluded  systems  are  general  multi¬ 
purpose  applications  such  as  Management  Information, 


Inventory  Control,  or  Payroll  systems.  However, 
when  feasible,  the  terms,  tools,  and  techniques 
employed  in  the  general  purpose  area  will  be  adopted 
or  adapted  to  support  management  of  computer 
resources  in  major  Defense  systems.  " 

Rationale:  This  paragraph  makes  clear  that  computer 
resources  are  not  included  under  the  terms  of  this 
directive  when  they  are  used  for  general  multi-purpose 
applications.  The  intent  is  to  address  the  computer 
resource  acquisition  issue  on  the  basis  of  application 
(embedded  as  a  component  of  a  Defense  system  or 
general  purpose  ADP)  rather  than  on  tiie  basis  of  the 
design  of  the  hardware  (specially  designed  or  off-the- 
shelf).  This  paragraph  also  states  that  resources  which 
are  employed  to  process  ADPE  procurement  in  the  gen¬ 
eral  ADP  area  should  be  used  by  acquisition  managers 
when  appropriate.  The  difference  is  that  the  approval 
process  will  be  under  the  control  of  the  Defense  acqui¬ 
sition  management  community  rather  than  the  financial 
community,  which  is  currently  the  case.  Acquisition 
managers  are  merely  making  use  of  established 
resources. 

Insert  new  paragraph  V.  A.  3  as  follows: 

"To  ensure  cost-effective  procurement,  embedded 
computer  resource  acquisition  shall  conform  to  the 
intent  of  P.  L.  89-306  (Brooks  Bill).  In  the  case  of 
major  Defense  systems,  the  system  acquisition  process 
as  specified  in  DOD  Directive  5000.2  (reference  (g)) 
provides  the  mechanism  which  will  ensure  proper  eval¬ 
uation  of  embedded  computer  resource  procurement. 
Specifically,  the  Decision  Coordinating  Paper  (DCP) 
for  Milestone  II  will  address  computer  resource  require¬ 
ments  and  provide  an  analysis  which  shows  that  the 
proposed  embedded  computer  resource  selection  is  the 
most  cost-effective  and  competitive  choice  in  the  con¬ 
text  of  system  requirements.  The  Defense  Systems 
Acquisition  Review  Council  (DSARC)  will  evaluate  the 
proposed  selection  and  recommend  approval  or  dis¬ 
approval  for  the  consideration  of  the  Secretary  of 
Defense.  In  the  case  of  less  than  major  Defense  sys¬ 
tems,  DOD  components  snail  incorporate  provisions 
in  their  review  process  to  ensure  the  principles  out¬ 
lined  above  are  met.  " 

Rationale:  This  paragraph  implements  management 
and  acquisition  of  computer  resources  through  the 
highly  effective  acquisition  review  process  established 
■■iv  DOD  Directive  5000.2.  The  DSARC  ensures  com- 
r.M-r.sive  cm r  .deration  of  all  technical  and  financial 
.  Sin*  ••  computer  resource  acqui sition  would 


now  be  closely  integrated  with  the  system  acquisition 
process,  duplication  of  effort  and  requirements  for 
approval  from  authorities  who  have  no  responsibility 
for  the  system  acquisition  would  be  eliminated. 

d.  Insert  new  paragraph  between  the  current  V.  B  and 
V.  C  paragraphs  as  follows: 

"Acquisition  of  ADPE: 

(1)  Acquisition  of  Computer  Resources:  Specially 
designed  (not  configured)  computer  equipment, 
or  commercially  available  computer  equipment 
which  is  acquired  by  a  contractor  and  embedded 
as  a  component  of  a  Defense  system  for  delivery 
to  the  government  may  be  acquired  by  DOD  com¬ 
ponents  without  a  delegation  of  procurement 
authority  from  GSA.  Approval  for  acquisition  of 
embedded  computer  resources  shall  be  delegated 
to  the  lowest  level  practical  and  in  most  cases  to 
the  System  Program  Manager.  Specifications  for 
embedded  computer  resources  must  be  written 

to  enhance  competition. 

(2)  If  the  government  provides  general  purpose  com¬ 
puter  equipment  or  specifies  a  particular  vendor, 
a  Delegation  of  Procurement  Authority  (DPA) 
must  be  obtained  from  GSA.  Each  DOD  component 
will  ensure  that  duplicate  approval  of  computer 
resources  is  eliminated  and  that  paperwork  asso¬ 
ciated  with  each  DPA  is  minimized.  " 

Rationale:  The  intent  of  this  paragraph  is  to  spe¬ 
cifically  state  those  cases  of  computer  resource 
procurement  which  do,  and  those  which  do  not, 
require  delegation  of  procurement  authority  from 
GSA.  This  statement  should  provide  clear  guidance 
to  DOD  components  and  eliminate  the  confusion 
that  typifies  authority's  reaction  to  most  requests 
for  procurement  authorization. 

e.  Change  paragraph  VI.  B  to  read  as  follows: 

"DOD  components  shall  implement  the  specific  pro¬ 
visions  of  this  instruction  through  the  policies  and 
procedures  for  which  they  have  cognizance.  DOD 
components  will  review  their  existing  regulations, 
specifications,  and  standards.  They  shall  modify, 
cancel,  or  supplement  then,  as  required  to  ensure 
consistency  with  the  policy  in  this  directive.  Imple¬ 
menting  directives  will  specify  the  method  of  acquisi¬ 
tion  (DODD  5000.29)  of  all  computer  resource  com¬ 
ponents  or  systems." 
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Rationale:  The  intent  of  this  paragraph  is  to  clearly 
state  that  DOD  components  must  implement  the  poli¬ 
cies  and  procedures  of  DOD  Directive  5000.  29  for  all 
system  acquisitions,  not  merely  for  major  Defense 
systems.  This  should  serve  to  decrease  some  of  the 
confusion  within  DOD  components  and  also  specify 
where  the  authority  and  responsibilities  lie. 

f.  Change  definition  D,  "Computer  Programs,  "  to  read 
as  follows: 

"Computer  Program.  A  series  of  instructions  or  state¬ 
ments  in  a  form  acceptable  to  computer  equipment, 
designed  to  cause  the  execution  of  an  operation  or 
series  of  operations.  Computer  programs  include 
such  items  as  operating  systems,  assemblers,  com¬ 
pilers,  interpreters,  data  management  systems, 
utility  programs,  and  maintenance/diagnostic  pro¬ 
grams.  They  also  include  application  programs  such 
as  electronic  warfare,  communications,  electronics, 
operational  flight,  strategic,  tactical,  automatic  test, 
crew  simulator,  and  engineering  analysis  programs. 
Computer  programs  may  be  either  machine  dependent 
or  machine  independent,  and  may  be  designed  to  satisfy 
the  requirements  of  a  specialized  process  of  a  particu¬ 
lar  system  or  support  system.  " 

g.  Change  definition  G,  "Embedded,  "  to  read  as  follows: 

"Embedded .  Adjective  modifier:  integral  to,  from  the 
design,  functional,  procurement,  operations  or  support 
point  of  view  espoused  in  DOD  Directive  5000.  I 
(  refe  rence  (a)) .  " 

Rationale:  The  intent  is  to  specify  the  entire  Defense 
svstem  environment  as  the  encapsulation  of  the  embedded 
computer  resources.  Thus,  any  computer  resource 
which  is  integral  to  the  operational  system  or  a  sup¬ 
porting  subsystem  would  be  classified  as  embedded  in 
the  the  Defense  system.  This  would  include  such  appli¬ 
cations  as  training,  maintenance,  analysis,  diagnostic, 
and  logistic  subsystems  as  well  as  special  and  auto¬ 
matic  test  equipment  which  directly  support  the  opera¬ 
tional  system.  The  Defense  community  must  control 
these  areas  to  produce  effective  systems,  on  schedule, 
and  at  reasonable  cost. 

h.  Add  definition  I,  "Embedded  Computer  System,"  as 
follows : 

"Embedded  Computer  System.  A  configuration  of  com¬ 
puter  resources  which  is  integral  to  a  Defense  system 
and  has  the  primary  purpose  of  controlling,  sensing, 
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interpreting,  processing,  or  otherwise  assisting  the 
operation  of  a  larger  system.  " 

Add  the  following  references: 

"(n)  DOD  Directive  7920.  1,  "Life  Cycle  Management 
of  Automated  Information  Systems,  "  October  17, 
1978" 

"(o)  DOD  Directive  7900.  3,  "Life  Cycle  Management 
of  Automated  Data  Processing  Systems,  "  DRAFT 


6.  CONFIGURATION  MANAGEMENT 


6.  I  BACKGROUND 

To  fully  capitalize  upon  the  weapon  system  flexibility  facilitated 
through  embedded  computer  system  software,  an  affective,  efficient 
configuration  identification,  control,  and  status  accounting  system  is 
mandatory.  While  the  import  of  Configuration  Management  (CM)  for 
hardware  has  long  been  recognized  and  successfully  effected,  software  — 
in  its  less  visible,  more  pervasive  nature  —  has  not  been  as  appreciated 
or  manageable.  In  the  absence  of  effective  CM,  particularly  in  a  multi- 
baselined  environment,  ECS  volatility  limits,  if  not  totally  denies,  the 
flexibility  fostered  in  software.  Recovery  from  such  a  state  is  a  verbotenly 
expensive  engineering  reconstruction  of  the  past  change  process,  usually 
traversing  backward  to  a  point  in  time  wherein  a  clear  linkage  can  be 
effected  between  functional,  allocated,  and  product  baselines. 

6.2  DISCUSSION 

As  stated  in  AFLCR  800-21,  the  purpose  of  configuration  manage¬ 
ment  is  to  apply  necessary  direction  and  surveillance  to  identify  and  docu¬ 
ment  the  function/physical  characteristics  of  ECS  equipment,  CPCI's, 
and  documentation  as  well  as  to  control  changes  to  these  characteristics 
and  report  change  status.  Historically,  the  implementation  of  hardware 
CM  has  been  successful.  The  majority  of  the  problems  associated  with 
CM  of  ECS  is  with  the  software  (or  firmware)  and  its  documentation.  The 
reason  for  this  probably  lies  with  the  less  tangible,  less  visible  nature  of 
software. 

The  basic  elements  for  CM  are  categorized  as  follows: 

•  Policies  and  procedures 

•  Identification  methods 

•  Established  baselines 

•  Change  control  methods 

•  Implementation 

•  Resources 
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6.2.1  Policies  and  Procedures 

The  configuration  management  guidance  provided  in  AFR  800-14 
and  AFLCR  800-21  is  considered  adequate.  The  process  of  detailing  of 
this  guidance  into  lower  indentured  procedures  and  tool  requirements  at 
the  ALC  level  (e.  g.  ,  envelopment  into  MM  MMI  MME.  MMEC  operating 
instructions),  however,  has  not  been  consistent  across  the  ALC's.  As  a 
result,  the  Operational/Support  Configuration  Management  Procedures 
(O/S  CMP's)  currently  in  circulation  vary  in  content  and  appear  oriented 
more  toward  CM  planning  than  toward  CM  procedures.  In  many  cases, 
further  detailing  will  consequently  be  necessary  prior  to  entering  the  soft¬ 
ware  change  process.  Detailed  CM  procedures/ requirements,  if  stand¬ 
ardized  across  ECS's  and  ALC's,  would  result  in  much  more  common¬ 
ality  between  O/S  CMP's  generated  for  the  various  ECS's,  as  well  as 
data  management  systems,  requirements  tracing  tools,  and  library 
systems. 

While  there  will  be  some  degree  of  difference  across  a  given  type 
ECS  software  (ATE,  ATD,  OFP,  EW,  G-E),  the  establishment  of  a  generic 
set  of  procedures  and  CM  tools  for  each  type  appears  reasonable.  It 
should  be  pointed  out  that  the  attempts  that  have  been  made  in  this  regard 
(e.  g.  ,  at  WR-ALC)  are  encouraged. 

6.2.2  Identification  Methods 

Bv  DOD  definition,  " c pr. f ; •  —'♦ion  identification"  is  a  document  or 
set  of  documents  that  defines  the  configuration  of  an  item.  In  this  sense, 
it  represents  one  or  more  material  objects  (documents).  As  a  part  of  con¬ 
figuration  management,  however,  it  is  not  grouped  with  material  objects 
but  with  operating  processes:  configuration  control  and  status  accounting. 

It  is  natural,  therefore,  when  discussing  the  functions  of  CM  to  expand 
the  scope  of  the  term  "configuration  identification"  to  that  of  a  third  pro¬ 
cess  that  performs  all  tasks  associated  with  identification  of  an  item's 
configu ration,  including  identification  of  the  CPCI's  in  a  system  and 
assignment  of  unique  item  identifiers  to  software  and  documents. 

The  Computer  Program  Identification  Numbering  (CPIN)  system 
delineated  in  AFLCR  800-21  adequately  provides  for  this  unique  identifier 
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for  controlling  the  physical  medium.  As  allowed  in  AFLCR  800-21,  how¬ 
ever,  auxiliary  methods  appear  to  ensure  closer  control  of  documenta¬ 
tion;  a  single  CPIN  will  be  assigned  to  the  total  CM  documentation  package 
of  a  given  ECS  program,  regardless  of  the  number  and  types  of  documents 
required  in  identifying  the  baseline.  The  cross-use  of  the  contractor 
documentation  tree  and  numbering  system  or  the  appendage  of  a  distinguish 
ing  dash  number  to  the  CPIN  itself,  should  assist  in  this  regard. 

6.  2.  3  Established  Baselines 

A  well-defined  baseline  is  one  of  the  cornerstones  of  good  CM. 
Without  a  defined,  identified,  and  documented  baseline  delivered  by  the 
developing  organization,  the  configuration  management  process  is  faced 
with  initial  difficulties  that  are  hard  to  overcome  in  the  best  of  circum¬ 
stances  and  are  further  compounded  by  subsequent  changes  to  the  original 
software. 

A  baseline  for  software  is  essentially  described  by  the  source  code 
and  its  documentation.  Documentation  should  describe  all  atributes  of  the 
software  such  as  requirements,  design,  usage,  functional  and  physical 
description,  inputs,  outputs,  technical  description  of  the  code,  and  test 
information. 

Inadequate  baseline  descriptions  are  existent  in  OFP,  EW,  ATE, 
ATD,  and  C-E  categories.  Primarily,  this  is  a  lack  of  documentation  or 
that  the  documentation  is  inaccurate  and  therefore  does  not  reflect  the 
true  state  of  the  software.  In  such  a  case,  software  support  cannot  be 
performed  without  reverse  engineering.  This  severely  impacts  the  qual¬ 
ity  of  each  product.  There  are  many  examples  of  poor  quality  software 
at  PMRT.  An  example  was  presented  in  Volume  IV  of  this  study  which 
indicated  25  to  40  percent  of  the  programs  will  not  function  when  initially 
received  at  the  Technical  Repair  Center.  Similar  quality  problems  exist 
in  all  five  ECS  categories  with  ATE  and  EW  ranking  as  the  worst. 

Based  on  subjective  analysis,  it  is  in  the  inadequate  baseline  area 
that  many  of  the  problems  in  CM  originate  and  continue  to  exist  through¬ 
out  system  life  cycle.  To  adequately  define  a  baseline,  the  documentation 
must  be  appropriate  and  complete.  One  of  the  primary  reasons  for  inade¬ 
quate  documentation  is  lack  of  resources.  Every  effort  is  resource- 
limited  and  every  development  manager  and  end-user  wants  the  most  for 


the  available  monies.  Another  problem  is  that  software  is  less  tangible 
and  visible  to  program  managers.  Most  emphasis  is  in  meeting  develop¬ 
ment  testing  and  production  deadlines  for  hardware.  Any  problem  asso¬ 
ciated  with  this  activity  impacts  software  development.  The  net  result 
is  that  software  is  the  last  in  the  development  cycle  and  suffers  most 
from  slippages,  changes,  or  modifications  to  the  program  schedule.  All 
effort  is  in  trying  to  complete  software  development  and  integration  into 
the  system,  and  software  documentation  rarely  is  adequately  prepared 
and  maintained  under  these  conditions. 

The  pre-deployment  performance  of  verification  and  validation 
(particularly  by  an  independent  agency  or  contractor),  preferably  cul¬ 
minating  in  a  demonstration  of  supportability  by  AFLC  at  PMRT,  and  the 
fulfillment  of  the  AFR  80-14  requirements  (by  AFTEC)  regarding  software 
suitability  and  supportability  add  significant  incentive  for  having  high  qual¬ 
ity  software,  a  well-defined  baseline,  and  adequate  documentation  at 
transfer. 

Typically,  more  than  one  version  of  a  software  product  exists  even 
at  PMRT  due  to  continued  engineering  development  or  optimization  efforts. 
This  is  normally  due  to  operational  considerations  and  will  not  be  addressed 
here. 

6.2.4  Change  Control  Methods 

O/S  CMP's  and  Operating  Instructions  (OI's)  for  change  control  have 
been  developed  by  the  various  ALC's  and  divisions  within  each  ALC. 

These  procedures  vary  in  quality  and  rigorousness  of  control;  however, 
they  are  a  step  toward  CM  of  software.  For  example,  the  FB-111-O/S 
CMP  avoids  use  of  the  TO-00-35D-54  deficiency  reporting  system  and 
yields  no  mention  of  assigning  MIP's  IAW  AFLCR  66-15,  while  the  SRAM 
and  B-52  Offensive  System  O/S  CMP's  require  rigid  adherence  to  these 
doctrines.  Another  problem  with  existing  procedures  is  that  they  are  not 
specific  in  establishing  step-by-step  rules  for  what,  when,  and  how  to 
perform  a  change.  Many  of  these  documents  are  only  a  repeat  of  top 
level  guidance  given  in  the  primary  references  for  CM;  AFR  800-14, 
MIL-STD  483-490,  AFR  63-4,  AFLCR  800-21.  CM  plans  often  omit  pro¬ 
cedures  for  support  software.  The  WR-ALC/MMEC  OI  800-14  represents 
a  significant  attempt  to  develop  procedures  for  support  software. 
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Another  deficiency  noted  is  the  absence  of  direct  correlation  of  CM 
plan  to  the  software  change  process.  The  requirements  for  documenta¬ 
tion,  reviews,  audits,  and  status  accounting  during  the  systems  engineer 
ing,  change  development,  change  testing,  and  validating  phases  are  cov¬ 
ered  but  not  always  explicit. 

Other  control  problems  exist  due  to  organizational  and  employment 

peculiarities.  In  some  cases,  the  control  authority  is  split  between  two 

organizations  without  clear  delineation  of  authority.  In  C-E,  many  of  the 

3 

Command,  Control,  and  Communications  (C  )  systems  are  a  support 
responsibility  of  AFLC,  yet  the  systems  are  one  or  few  of  a  kind  which 
reside  at  a  user  location.  Although  the  configuration  management  respon¬ 
sibility  rests  with  AFLC,  it  is  actually  the  user  who  has  the  opportunity 

3 

to  amend  or  change  the  C  system.  Furthermore,  the  user  is  the  agency 
which  first  recognizes  the  need  for  a  system  change.  If  the  user  is  par¬ 
ticularly  conscientious,  any  change  is  coordinated  with  AFLC  prior  to  its 
incorporation;  however,  most  changes  are  unilaterally  done  and  then 
relayed  to  AFLC.  Operational  capability  pressures  substantiate  the  user 
actions,  but  configuration  management  actions  are  implemented  by  an 
agency  other  than  that  agency  with  the  responsibility. 

ATD  has  a  similar  situation  in  that  the  basic  weapon  system  may 
undergo  a  change  which  requires  a  change  to  the  trainer.  First,  there 
is  a  requirement  that  the  trainer  be  concurrently  updated  with  the  weapon 
system  or  else  the  trainer  loses  its  validity.  Secondly,  most  of  the 
trainers  are  located  at  user  sites  and  are  operated  and  maintained  by  the 
users  although  the  overall  support  responsibility  is  with  Ogden  ALC. 
AFLC  has  attempted  to  control  the  trainer  configurations  by  applying  the 
DEPS  concept,  yet  the  dual  path  of  change  accomplishment  exists.  The 
user  pressures  are  to  keep  the  trainer  operative,  but  assurance  of  long 
range  support  is  an  AFLC  responsibility.  This  dilemma  is  extensively 
addressed  in  Volume  III  of  this  report. 

In  summary,  the  change  control  procedures  exist  and  are  adequate. 
Much  improvement  could  be  accomplished  in  uniformity  and  specificity, 
and  possibly  the  process  could  be  made  smoother  for  C-E  and  ATD. 
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6.2.5  Implementation 

Implementation  is  the  major  element  for  improvement  in  the  con¬ 
figuration  management  process.  Basically,  CM  suffers  in  this  area  more 
so  than  from  the  lack  of  procedural  and  regulatory  guidance.  AFR  800-14 
initiates  rather  explicit  guidance  and  describes  a  method  to  manage  the 
configuration  of  software.  Several  amplifying  documents  and  regulations, 
including  AFLCR  800-21  (change  to  AFLCR  800-21  is  in  coordination), 
have  been  published  which  expand  this  initial  guidance.  Given  the  policies 
and  procedures  are  adequate,  the  basic  shortcoming  of  configuration  man¬ 
agement  would  have  to  rest  in  the  implementation.  This  would  indicate 
one  of  two  things:  (1)  there  is  a  lack  of  management  emphasis  or  (2)  it 
is  impossible  to  do  the  job  with  current  resources.  Differences  in  the 
degree  of  implementation  vary  for  each  ALC  and  even  between  systems 
at  a  given  ALC.  This  is  partially  due  to  the  maturity  of  each  system  and 
the  unique  circumstances  surrounding  its  development.  Implementation 
is  most  closely  tied  to  resources  and  management  emphasis. 

6.2.6  Resources 

The  remaining  key  to  good  CM  is  resources.  This  includes  the  CM 
system  itself  whether  manual  or  automatic,  personnel,  equipment,  and 
facilities.  If  an  adequate  baseline  exists  and  the  procedures  and  regula¬ 
tions  are  adequate,  the  only  open  question  is  the  necessary  resources  to 
implement  CM.  Tasks  that  determine  the  resources  involved  include: 

•  A  specific  approval  authority  must  be  established 

•  Master  copies  of  software  and  documentation  must  be  pre¬ 
served  and  controlled 

•  Development  copies  of  the  software  must  be  available  for 
engineering  and  test  uses 

•  An  initial  data  base  for  the  CM  system  must  be  created 

•  A  library  of  documentation  and  software  must  be  created 
with  its  own  accessing  and  control  instructions 

•  Sufficient  equipment,  facilities,  and  personnel  must  be 
available  to  implement  all  of  these  activities 

•  The  resources  must  be  considered  against  some  scheme 
for  implementation  such  as  an  O/S  CMP 
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Where  trade  studies  so  indicate,  the  use  of  automated  tools  should  be 
considered  to  improve  accuracy,  speed,  and  cost  effectiveness. 

Several  problems  addressed  in  preceding  paragraphs  could  con¬ 
ceivably  be  alleviated  through  adequate  resources.  As  previously  stated, 
management  is  under  pressure  to  deliver  the  most  product  (capability) 
for  the  money.  This  situation  leads  to  a  management  perspective  of  CM 
in  that  it  takes  more  time  and  resources  to  address  CM.  This  drives  soft¬ 
ware  development  costs  upward.  If  the  management  responsibility  is  to 
"develop  only"  and  to  stay  within  a  budget,  then  CM  enforcement  suffers 
and  so  does  the  quality  of  documentation  and  software.  When  considered 
from  a  life  cycle  cost  perspective,  it  is  cheaper  to  catch  and  correct  soft¬ 
ware  deficiencies,  ambiguities,  and/or  oversights  early  in  development 
as  opposed  to  correcting  them  after  the  software  design  is  committed  to 
a  particular  configuration.  On  the  other  hand,  developers  must  have  some 
flexibility  to  accomplish  design  and  software  products  or  else  their  pro¬ 
ductivity  rate  is  too  low.  There  is  a  tradeoff  of  how  much  CM  discipline 
to  enforce  and  the  determination  of  "how  much"  is  more  a  matter  of  pre¬ 
vious  experiences  than  of  following  a  formula.  Experience  levels  of  CM 
personnel  have  improved  in  recent  years;  however,  many  of  the  AFLC 
systems  that  require  software  support  are  from  the  era  when  enforcement 
of  CM  discipline  was  inadequate.  As  a  result,  the  documentation  and  soft¬ 
ware  combine  into  an  ill-defined  (or  in  some  cases,  not  described)  base¬ 
line.  Support  of  such  systems  poses  severe  problems  both  managerially 
and  technically. 

6.3  RECOMMENDATIONS 

1.  Detail  the  configuration  management  provided  in  AFR  800-14 
and  AFLCR  800-21  into  ALC  division  and  branch  level  pro¬ 
cedures,  advisedly  in  the  form  of  Operating  Instructions 
(OI's).  Action  should  be  taken  by  HQ  AFLC  to  ensure  that 
such  procedures  are  consistent  across  like  types  of  ECS's 
(i.e.  ,  OFP,  EW  ATD.  ATE,  C-E).  These  OI' s  should  be 
employed  as  items  for  AFLC  functional  inspections. 

2.  Review  the  suitability  of  the  CPIN  system  for  controlling 
baselining  documentation,  particularly  for  computer  pro¬ 
grams  employed  in  a  multi- version  environment  involving 
more  than  a  single  ECS  and  a  single  weapon  system. 


3. 


Review  the  O/S  CMP  outline  recommended  in  AFLCR 
800-21  with  the  thought  of  reorienting  it  more  toward 
specific,  detailed  procedures  rather  than  toward  top  level 
planning.  The  CRISP  CM  section  might  warrant  change  to 
better  accommodate  the  CM  planning  aspects.  Considera¬ 
tion  should  also  be  given  to  modifying  both  these  outlines 
to  accommodate  the  various  types  of  software  that  may  be 
addressed  in  a  weapon  system  level  O/S  CMP  (i.  e.  ,  OFP, 
ATE,  etc.,  including  necessary  support  software). 

4.  As  suggested  in  Section  3,  formulate  a  generic  set  of  soft¬ 
ware  change  activities  and  associated  O&S  functions  which 
are  applicable  across  the  five  ECS  types.  The  CRISP  and 
O/S  CMP  outlines  presented  in  AFLCR  800-21  should  be 
modified  to  reflect  this  partioning.  The  work  breakdown 
structure  at  the  ALC's  should  also  be  adjusted  to  more 
closely  align  with  these  functions /activities . 

5.  Implement  the  recommendations  tendered  in  Section  9  to 
ensure  suitable  baseline  descriptions  are  available  at 
ECS  PMRT  and  are  kept  current  (with  respect  to  the 
physical  media)  over  the  life  cycle. 

6.  Enhance  accuracy,  speed,  and  cost  effectiveness;  develop 

a  common  set  of  CM  tools  (e.  g.  ,  data  management  systems, 
requirements  tracing  tools,  library  systems)  across  ALC's 
and,  where  applicable,  across  ECS  types. 

7.  Through  close  coordination  with  AFSC,  encourage  the  pre¬ 
deployment  use  of  the  procedure  format  evolving  from 
recommendation  1  and  the  tools  selected  in  recommenda¬ 
tion  5. 

8.  Reexamine  the  requirements  set  forth  in  AFLCR  800-21 
and  AFLCR  66-15  regarding  the  use  of  MDR's,  MIP's, 
and  TCTO's  to  report,  track,  and  release  ECS  software 
changes.  A  "tailored"  process  more  closely  attuned  to  the 
software  change  cycle  (for  emergency,  urgency,  routine, 
and  block  change  concepts)  appears  in  order. 

9.  Conduct  a  tradeoff  analysis  to  evaluate  centralized  change 
management  versus  a  decentralized  process  (for  C-E  and 
ATD).  Roles  and  missions  of  involved  agencies  should  be 
carefully  considered.  If  split  software  support  is  deter¬ 
mined  necessary  for  a  special  situation,  support  should  be 
aggregated  at  one  location  with  CM  performed  as  a 
consolidated/coordinated  effort. 

10.  Reevaluate  the  manpower  and  staffing  plans  for  each  ECS 
currently  entering  the  inventory  to  ensure  that  proper  CM 
resources  (tools,  personnel,  equipment,  and  facilities) 
are  programmed.  Emphasize,  where  appropriate,  the 
import  of  effective  life  cycle  CM. 
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11.  Ensure  that  the  training  planning  recommended  in  Section 
adequately  addresses  CM  requirements. 
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7.  FACILITY  PLANNING/FUNDING/MAINTENANCE 

7.  1  BACKGROUND 

Extensive  resources  are  expended  in  the  Embedded  Computer  Sys¬ 
tem  (ECS)  support  facility  planning  process  in  attempts  to  identify  and 
obtain  necessary  facilities,  equipment,  and  trained  manpower.  The  plan¬ 
ning  process  for  the  ECS  support  facility,  also  called  Avionics  Integra¬ 
tion  Support  Facility  (AISF),  involves  explicit  definition  of  requirements, 
estimating  the  i_ost  of  items  to  be  acquired  and/or  developed  and  obtaining 
the  necessary  approvals  for  the  funding.  This  process  must  interface 
with  long  approval  cycles  such  as  the  federal  budget  cycle  and  the  MCP 
cvcle.  and  can  span  over  years.  Changing  personnel  in  the  planning  pro¬ 
cess,  vague  and  changing  system  and  support  requirements,  cost  changes, 
etc.  ,  that  go  along  with  a  drawn  out  process  further  compound  the  delays 
within  the  AI.Cs.  There  is  a  general  feeling  of  a  lack  of  dedication  by 
the  implementing  commands  for  setting  aside  resources  for  providing 
long  range  support  requirements,  A  particular  example  has  been  the 
planning  process  which  has  taken  place  on  the  E-3A  AISF. 

7.2  DISCUSSION 

The  discussion  begins  with  a  description  of  an  ideal  AISF  planning 
process  followed  by  an  analysis  of  the  performance  of  the  planning  per¬ 
formed  for  the  E-3A  system.  Additional  discussions  are  then  provided 
to  emphasize  the  problem  areas. 

7.2.1  AISF  Planning  Process 

An  ideal  AISF  planning  process  is  delineated  in  the  sequence  shown 
in  Figure  7-1  with  the  desired  time  phasing  with  respect  to  the  ECS  life 
cycle.  The  steps  can  overlap  with  some  steps  being  done  in  parallel; 
however,  a  sequential  process  is  easiest  to  follow  with  progress  more 
easily  measured.  The  major  steps  consist  of: 

•  PMD /  PM P  documentation 

•  Preliminary  CRISP  document 

•  Establish  support  concept 
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•  Update  CRISP  document 

•  Implementation  plan 

•  Coordination  and  approval 

7.2. 1.1  PMD/PMP  Documentation 

The  PMD/PMP  should  provide  for  the  establishment  of  a  ground 
facility  to  perform  software  support.  It  should  also  clearly  state  where 
the  responsibility  lies.  Because  the  PMD/PMP  is  directed  primarily 
toward  the  weapon  system,  the  AISF  is  often  overlooked.  When  no  direc¬ 
tion  is  provided,  justification  for  a  need  later  on  is  made  extremely 
difficult. 

7.  2.  1.2  Preliminary  CRISP  Document 

The  initial  draft  will  attempt  to  establish  how  support  is  to  be  per¬ 
formed  during  concept  development.  Segments  which  depend  upon  an  estab¬ 
lished  concept,  such  as  organic  versus  contractor,  will  be  left  open  to-be- 
supplied  later.  This  preliminary  CRISP  document  will  be  utilized  to  help 
establish  the  support  concept. 

7.2.  1.3  Establish  Support  Concept 

Many  alternatives  exist  for  performing  software  support.  This  step 
performs  the  necessary  analysis  in  order  to  establish  a  workable  concept 
for  support  in  an  austere  funding  environment.  Some  of  the  options 
include: 

•  Organic  versus  contractor  support 

•  Mixed  support  —  some  organic,  some  contractor 

•  Combined  or  separate  software  support  and  system 
integration 

•  Integrated  with  other  multi- system  support  capability 

•  Integrated  with  maintenance  capability 

Definition  is  required  on  the  design  concepts  with  ROM  cost  data 
established.  The  Generic  Logistic  Decision  Tree  (GLDT)  analysis  (AFLCR 
400-XX)  is  required  to  resolve  the  organic  versus  contractor  question. 
These  analyses  are  the  responsibility  of  the  supporting  command. 
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7.2.  1.4  Update  CRISP  Document 


With  the  support  concept  established,  the  CRISP  should  be  com¬ 
pleted.  The  CRISP  should  now  provide  details  on  a  support  concept  such 
as : 

•  Management  concept 

•  Configuration  management 

•  Documentation 

•  Pe  rsonnel  / 1  raining 

•  Support  equipment /software 

•  Facility  (brick  and  mortar) 


7.2.  1 .  ?  Implementation  Plan 

With  the  CRISP  defining  what  is  needed,  an  implementation/ 
development  plan  should  be  written  describing  how  to  obtain  the  resources. 
The  acquisition  philosophy  must  be  established,  such  as: 

•  Items  needing  development 

•  Turnkey  versus  piece  pa  rt/integ  ration 

•  Modular  approach 


•  Organic  versus  contractor  integration 

In  addition  (and  importantly),  the  plan  should  describe: 

•  Funding  (how  much,  what  category,  and  how  obtained) 

•  Manpower  (plans  on  how  to  meet  the  requirements) 

•  MCP  (how  best  to  obtain  the  needed  housing  for  the 
equipment) 


Coo rd ination  and  Approval 


Proposals  are  made  to  obtain  approvals  on  funds,  manpower,  and 
MCP,  This  approval  process  is  complicated  by  the  federal  budget  cycle 
and  the  MCP  cycle. 

With  the  completion  of  the  planning  process,  attention  can  be 
directed  to  the  next  phase  of  the  AISF  acquisition/development  process 
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(see  Section  7.  3  for  a  discussion  of  the  complete  process).  The  planning 
process  must  he  completed  early  with  sufficient  time  remaining  in  the 
FSED  phase  so  that  AISF  development  also  can  be  completed  in  the  FSE1) 
phase. 

7.2.2  E-3A  Planning  Process 

An  analysis  is  made  of  the  E-3A  planning  process  in  an  attempt  to 
uncover  the  problem  areas  causing  the  long  time  delays. 

A  chronology  of  the  planning  process  is  shown  in  Table  7-1,  indi¬ 
cating  that  the  total  span  was  over  five  (5)  years.  Remnants  of  the  pro¬ 
cess  still  remain.  With  a  projection  made  of  the  steps  still  required  to 
be  performed  in  the  AISF  development  process,  as  shown  in  Figure  7-2, 
the  estimated  penalty  is  2.  0  years.  With  respect  to  the  original  PMRT 
date  of  October  1980,  the  penalty  would  actually  be  4.  0  years. 

It  is  difficult  to  pinpoint  the  problems  to  one  area.  Some  of  the 
reasons  put  forth  include: 

«  Delays  in  the  weapon  system  development 

•  AISF  relegated  lower  priority  over  additional  aircraft 
buys  and  enhancements 

•  E-3A  SPO's  continuing  insistence  on  using  the  develop¬ 
ment  contractors  facilities 

•  Ineffective  CRWC  and  CRISP 

•  Weapon  system  complexity 

•  Aborted  contractor  studies 

•  Sole  source  predicament  with  large  aircraft  manufacturer 

•  Federal  budget  cycle 

Even  with  the  funding  approved  as  a  result  of  the  April  1979  in-depth 
review,  many  concerns  still  remain,  such  as: 

•  Funds  adequacy  —  what  will  be  the  resulting  configuration 
with  approval  given  to  the  low-end  of  estimated  cost  and 
in  the  presence  of  rising  costs. 

•  MCP  approval  —  MCP141-763  approval  is  still  pending. 
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Table  7-1.  Chronology  of  the  E-3A  AISF  Planning  Process 


Date 

Activity 

August  1974 

MOA  between  TAC/AFLC  defined  division  of 
software  support  assignment. 

December  1974 

AFLC's  requirement  was  patterned  around 
Boeing's  AIL. 

February  1975 

Original  CRISP  issued  (Life  Cycle  Computer 
Program  Management  Plan). 

June  1975 

Cost/Tradeoff  study  on  AIL. 

September  1976 

SPO  initiated  a  request  to  Boeing  to  submit 
contract  change  data  for  support  facility. 

April  1977 

Boeing's  CCP  issued  to  perform  study  (pro¬ 
posal  never  accepted). 

January  1977 

OC-ALC  reviewed  an  independent  contractor 
(TRW)  study  on  E-3A  support  concept. 

September  1977 

OC-ALC  integrated  previous  analyses  in  a 
document  entitled  "E-3A  Software  Support 
Assessment.  " 

September  1977 

AISF  cost  was  submitted  by  AFLC/SPO  for 
entry  into  FY79  POM  at  $35M. 

January  1^78 

E-3A  overall  program  restructured  replac¬ 
ing  $3 5M  in  FY79  POM  by  $9.  5M  (for 
transfer  of  Boeing's  AIL). 

|  February  1978 

E-3A  C.RWG  subgroup  formed  to  restudy 

AISF.  CRISP  reissued. 

May  1«78 

t 

Subgroup  presentation  to  USAF  General 

Officer  Steering  Group  with  an  estimate  of 
$35.  3M  to  $38.  8M. 

June  1978 

OC-ALC  completed  a  study  proposing 
"Organic  Implementation,  "  with  an  estimate 
of  $35.  3M  to  $48.  1M. 

F  ebu  ra  ry  1979 

AFLC/AFSC  MOA  regarding  AISF  acquisi¬ 
tion  concept. 

March  1979 

MCP  for  TAFB  Bldg.  3220  extension. 

April  1979 

E-3A  in-depth  review  results  in  procure¬ 
ment  and  funding  approval  for  $30.  5M. 

May  1979 

E-3A  AISF  implementation  plan. 
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•  Long  lead  time  equipment  —  the  rapidity  with  which  equip¬ 
ment  can  be  acquired  or  developed  is  uncertain.  Priority 
of  needed  avionic  equipment  for  the  AISF  over  those  needed 
for  weapon  system  production  is  uncertain. 

Some  constraints,  such  as  the  federal  budget  cycle  and  the  MCP 
cycle,  are  "cast  in  concrete"  and  will  be  very  difficult  to  change.  Two 
items  which  are  disturbing  and  which  should  be  workable  are: 

•  Low  priority  given  to  the  AISF 

•  Contractor's  Avionics  Integration  Laboratory  (AIL)  versus 
AISF 

Experience  should  show  (A- 7,  F-lll)  that  software  cannot  be 
expected  to  be  troublefree.  Even  if  relatively  problem  free,  users  will 
want  to  make  changes  in  the  software.  A  ground  laboratory  facility  uti¬ 
lizing  actual  avionic  equipment  provides  the  most  realistic  environment 
(short  of  flight  testing)  for  performing  software  verification  and  system 
integration.  This  is  especially  true  for  highly  complex  systems  where 
interpretive  computer  simulations  on  a  large-scale  general  purpose  pro¬ 
cessor  would  be  very  difficult  and  time  consuming.  It  should  be  decided 
early-on  whether  an  AISF  is  needed.  If  a  facility  is  needed  for  software 
development,  an  AISF  is  needed  for  O&S.  If  a  decision  is  made  that  it  is 
required,  every  effort  should  be  given  to  the  acquisition  process.  The 
AISF  acquisition  should  have  as  high  a  priority  as  the  software  develop¬ 
ment  facility. 

The  early  planning  on  the  E-3A  support  capability  called  for  the  use 
of  the  Avionics  Integration  Laboratory  (AIL)  which  was  developed  by  the 
prime  contractor  for  use  during  FSED.  The  plan  was  to  transfer  the  AIL 
upon  completion  of  its  activities  at  the  contractor's  facility.  There  are 
very  good  reasons  why  this  early  plan  was  not  satisfactory,  such  as: 

•  Contractors  can  present  convincing  arguments  against 
releasing  the  equipment.  ECS  enhancements  which  follow 
initial  development  follow  one  after  another  tieing  up  the 
facility.  The  AIL  originally  planned  to  be  available  around 
1980  is  now  planned  to  be  used  by  the  contractor  until  1987. 

•  Because  the  AIL  was  not  developed  with  intentions  of  being 
used  by  the  AF  community,  documentation  is  inadequate 
and  the  assembly  language  coding  in  the  environment  simu¬ 
lator  is  difficult  to  follow. 


•  Because  of  the  long  duration  of  the  development  phase, 

the  AIL  components  need  refurbishment  and  items  such  as 
the  minicomputer  are  archaeic  and  no  longer  maintained. 

In  audition,  the  AIL  alone  does  not  provide  the  software  test  stands 
needed  foi  performing  software  verification,  such  as  the  software  devel¬ 
opment  laboratory  used  by  the  contractor.  However,  this  latter  criticism 
is  on  completeness  rather  than  on  the  original  support  concept  philosophy. 

Without  an  extensive  tradeoff  study  substantiating  utility,  AFLC 
should  resist  the  concept  of  "handing  down"  or  transferring  to  the  O&S 
community  the  facility  utilized  during  FSED.  If  and  when  delivery  is 
made,  the  facility  will  typically  be  too  late,  badly  in  need  of  upgrading, 
and  poorly  documented.  A  support  concept  must  be  adopted  separate 
from  the  development  facility.  The  separate  facility  can  duplicate  and 
parallel  sigments  of  the  development  facility.  However,  it  is  important 
that  they  be  physically  separate.  The  "handing  down"  philosophy  can  only 
minimize  and  detract  from  the  full  responsibility  of  establishing  the  O&S 
facility.  It  is  too  readily  used  as  an  easy  solution  by  the  implementing 
command. 

Secondly,  a  clear  understanding  must  be  established  on  the  responsi¬ 
bilities  of  the  implementing  and  supporting  commands,  especially  with 
respect  to  funding.  It  is  important  to  establish  ground  rules  early,  such 
as  establishing  whether  support  should  be  contractor  or  organic. 

It  should  be  noted  that  having  a  support  capability  prior  to  PMRT 
can  be  of  great  benefit.  Valuable  experience  can  be  gained  in  setting  up 
test  procedures,  familiarization/training  on  the  AISF  hardware,  and  estab¬ 
lishing  configuration  management  procedures.  Early  establishment  of  a 
separate  facility  also  minimizes  the  "sole  source"  predicament.  Depend¬ 
ing  on  the  experience  gained  by  organic  personnel,  the  O&S  facility  can 
be  utilized  to  scope  proposed  contractor  changes  as  well  as  perform 
independent  verification  and  validation. 

There  is  also  a  valid  requirement  that  the  software  which  is  trans¬ 
ferred  to  the  logistics  command  be  supportable.  Many  times  current  pro¬ 
grams  do  not  allow  any  time  for  a  demonstration  of  this  capability,  or 
even  sufficient  time  for  training  to  attain  this  capability.  It  cannot  be 


7-9 


attained  by  engineers  sitting  at  their  desks  reading  documents.  EarLy 
establishment  of  the  facility  and  interactions  with  the  hardware/software 
is  needed. 


7.3  SUPPORT  FACILITY  ACQUISITION/DEVELOPMENT  PROCESS 

The  support  facility  capability  build-up  is  described  in  this  para¬ 
graph  as  consisting  of  the  five  steps  or  phases  shown  in  Figure  7-3.  The 
steps  are  basically  the  same  as  those  for  any  typical  system  development. 
Description  of  the  steps  is  given  in  the  following,  highlighting  the  impor¬ 
tant  considerations. 

7.3.1  Planning 

This  step  has  been  described  in  the  previous  paragraphs.  Additional 
comments  follow. 

One  of  the  major  tradeoffs  to  be  performed  is  the  question  of  in-house 
versus  contractor  in  performing  O&S.  If  the  tradeoff  analysis  concludes 
in  favor  of  an  organic  support  facility,  the  location  at  an  ALC  is  established 
according  to  where  the  management  responsibility  resides.  The  Generic 
Logistic  Decision  Tree  (GLDT)  analysis  will  be  utilized  for  the  in-house 
versus  contractor  determination. 

When  the  location  of  the  facility  is  established  at  an  ALC,  the  brick 
and  mortar  requirements  such  as  floor  space,  power/cooling  require¬ 
ments,  etc.  ,  have  to  be  defined.  This  determination  is  required  early 
because  any  required  Military  Construction  Proposal  (MCP)  approvals 
and  the  needed  facility  modifications  are  time  consuming  processes.  This 
planning  will  also  very  likely  be  interlaced  with  the  integrated  support 
planning  being  performed  at  the  locale  of  the  proposed  facility.  Compati¬ 
bility  with  the  other  plannings  will  be  required. 

The  facility  implementation  plan  should  address  facility  (brick  and 
mortar),  equipment,  personnel,  training,  documentation,  contract  sup¬ 
port,  and  management  approaches  with  emphasis  on  how  implementation 
is  going  to  be  performed.  Schedules  and  funding  estimates  are  the  major 
outputs  of  this  planning  task. 
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With  the  implementation  plan  and  supporting  viewgraphs,  a  series 
of  reviews  will  be  performed  in  an  effort  to  obtain  approval  for  the  estab¬ 
lishment  of  the  proposed  facility.  Upon  receiving  approval,  the  process 
proceeds  to  the  next  phase. 

7.3.2  System  Requirements 

System  requirements  analyses  are  performed  in  this  phase  to  estab¬ 
lish  a  functional  baseline  for  the  AISF.  The  additional  trade  studies  per¬ 
formed  in  this  phase  will  determine  the  top  level  hardware  and  software 
requirements.  The  facility  types  at  this  stage  should  be  clear  with  the 
complement  of  the  different  approaches  and  tasks  selected  (scientific 
simulation,  ICS,  CMAC,  DE,  stimulators).  The  hardware  and  software 
configuration  items  should  here  be  known.  This  allocation  of  the  AISF 
system  requirements  into  the  hardware  and  software  items  is  documented 
into  the  system  specification. 

With  a  clearer  picture  of  the  overall  configuration  of  the  AISF,  an 
update  will  be  made  of  the  implementation  plan  prepared  initially  in  the 
last  phase.  The  schedules  should  be  carefully  redeveloped  with  proper 
phasing  so  the  system  will  be  available  for  demonstration  at  the  required 
date. 

In  this  phase,  procurement  should  be  initiated  on  the  long  lead  time 
items.  One  item  which  stands  out  is  the  minicomputer  and  peripherals 
required  for  the  simulation  host  processor.  A  selection  process  must  be 
performed,  which  entails  assessing  the  total  SHP  requirements  including 
the  throughput.  It  should  include  such  considerations  as  growth,  reliabil¬ 
ity,  cost,  integrated  support  compatibility,  etc.  Procurement  should 
begin  as  soon  as  possible  after  the  selection  process  so  that  the  hardware 
and  software  will  be  available  for  full  use  at  the  beginning  of  the  develop¬ 
ment  phase.  This  minicomputer  should  be  available  in  time  for  the  devel¬ 
opment  of  the  SHP  real  time  support  software. 

Another  long  lead  time  item  is  the  engineering  data  base  management 
software.  The  requirement  for  this  software  should  include  the  mainte¬ 
nance  of  specific  data  bases  (such  as  requirements)  and  the  use  of  assist¬ 
ance  in  performing  elements  of  configuration  management.  This  software 
should  be  available  early  in  the  development  phase.  An  associated  effort 


7-11 


concerns  the  formation  of  the  AISF  software  development  standards  and 
procedures.  Early  definition  is  essential  to  maintaining  configuration 
control  over  the  development  software. 

In  this  phase,  any  required  facility  (brick  and  mortar)  modification 
and  preparation  should  be  performed. 

7.  3.  3  Development 

This  phase  begins  with  the  establishment  of  the  requirements  for 
the  individual  hardware  and  software  configuration  items  which  must 
either  be  acquired  or  developed.  The  first  specification  which  would  be 
developed  will  be  the  Type  B  specifications  written  for  both  the  acquired 
and  developed  items.  The  hardware  and  software  items  will  include: 

•  Avionics  hardware 

•  Special  test  equipment 

•  Simulation  software 

•  Data  reduction  and  analysis  software 

•  Data  management  system 

•  Interface  units 

The  development  process  will  proceed  as  shown  in  Figure  7-3  for 
the  developed  items.  Procurement  will  be  initiated  for  the  purchased 
items.  Some  support  software  such  as  EDMS  and  simulation  models 
should  be  available  from  established  facilities  at  ALC's  and  other  Air 
Force  organizations.  Type  C  specifications  will  be  documented  for  the 
developed  items  and  the  acceptance  test  plans /procedures  developed  for 
each  individual  item. 

The  purchased  special  test  equipment  must  undergo  acceptance  test¬ 
ing  upon  delivery.  These  items  could  include  the  CMAC,  the  SHP/avionics 
processor  interface  unit  and  the  stimulators.  Special  test  software,  if 
required,  will  be  developed  and  used  for  testing  these  special  test 
equipment. 
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Facility  Acquisition/Development  Sequence 


Code  and  debug  of  each  unit  of  software  is  performed  before  it  is 
integrated  with  other  units  of  the  CPCI.  Verification  testing  of  each 
CPCI  is  then  performed.  If  special  purpose  software  drivers  are  needed, 
they  are  developed  concurrent  to  the  verification  procedures. 

The  final  task  in  this  development  phase  is  the  development  and  docu 
mentation  of  the  AISF  acceptance  test  plans  and  procedures. 

7.3.4  Integration 

The  hardware  and  software  configuration  items  are  integrated 
together  in  this  phase  to  perform  system  integration  testing. 

Initially,  a  hardware/hardware  integration  should  be  performed. 
During  this  integration,  all  hardware  is  assembled  and  tested  to  the 
extent  possible  without  the  AISF  real  time  software.  Special  test  soft¬ 
ware  could  be  used  for  this  testing.  If  there  are  CPCI-to-CPCI  inter¬ 
faces,  the  software/software  integration  will  next  be  performed  as  the 
necessary  equipment  become  available. 

The  system  integration  testing  which  follows  must  successfully 
show  that  the  complete  requirements  as  defined  in  the  Type  A  and  B 
specifications  have  been  satisfied.  Documentation  produced  and  used 
during  this  phase  consists  of  the  test  results  document,  user's  manual, 
and  Type  C  specification  (updated). 

Acceptance  testing,  as  per  acceptance  test  plan/procedures,  cul¬ 
minates  this  integration  testing  phase. 

7.3.5  Demonstration 

This  phase  consists  of  a  demonstration  of  the  total  system  including 
hardware,  software,  personnel,  and  procedures  that  it  is  capable  of  per¬ 
forming  O&S  on  the  operational  software.  It  is  a  demonstration  of  sup- 
portability  with  its  limitations  to  upper  management  and  interested  parties 
It  should  include  a  demonstration  of  the  CM  procedures,  V&V,  and  flight 
test  support  capability. 
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Figure  7-4  shows  a  top  level  acquisition/development  schedule. 

The  major  tasks  are  listed  on  the  left  hand  column.  The  schedule  shows 
where  these  tasks  fall  within  the  five  phases.  Typical  durations  are  shown 
for  the  five  phases.  In  the  worst  cases,  the  acquisition/development  pro¬ 
cess  can  be  a  4-  to  5-year  undertaking.  This  prospect  emphasizes  the 
importance  of  timely  accomplishment  of  each  task  and  properly  time 
phasing  the  different  tasks  to  minimize  the  total  development  period. 

If  the  software  support  facility  was  developed  according  to  the  pre¬ 
cept  of  the  Air  Force  policies  and  procedures,  the  development  sequence 

» 

of  the  facility  with  respect  to  the  ECS  life  cycle  would  appear  as  shown  in 
Figure  7-5.  The  important  time  phasing  requirement  is  that  the  comple¬ 
tion  of  the  facility  demonstration  would  occur  on  or  prior  to  PMRT.  As 
long  as  this  requirement  is  met,  the  start  of  the  development  process  is 
somewhat  immaterial.  Overlying  the  activities  are  the  key  planning  docu¬ 
mentations  utilized  to  define  the  facility  contents. 

7.4  FACILITY  MAINTENANCE 

Planning  for  the  establishment  of  a  software  support  facility  or 
AISF,  by  necessity,  includes  the  establishment  of  maintenance  concepts 
and  resource  requirements.  Some  of  the  considerations  which  must  be 
made  are: 

•  The  source  and  availability  of  repair  facilities  and 
capabilities. 

•  The  level  (concept)  of  sparing  and  the  availability  of  funds 
to  accomplish  provisioning. 

•  Concept  of  repair  for  commercial  products,  i.  e.  ,  original 
vendor,  or  third  party.  Note:  while  third  party  repair  of 
commercial  computers  appears  attractive  from  a  theo¬ 
retical  cost  standpoint,  the  time  cost  in  mission  support 
and  lost  engineering  manhours  can  more  than  offset  the 
savings  of  such  a  maintenance  concept.  (A  th^rd  party 
has  the  maintenance  contract  on  the  Interdata  8/32  at 
WR-ALC  in  the  F-15  facility.  The  down-time  on  that 
piece  of  equipment  has  been  as  much  as  a  month  and  more 
at  one  time.  ) 
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AISF  maintenance  is  a  multi-task  job.  The  kinds  of  maintenance 
range  from  the  commercial  electronics  to  the  operational  hardware  and 
includes  support  software. 

The  various  software  and  hardware  to  be  maintained  will  be  defined. 
Then  a  suggested  means  of  maintaining  each  will  be  discussed.  It  is  pos¬ 
sible  that  any  part  of  the  AISF  could  be  maintained  organically  or  by  a 
contractor.  There  are,  however,  some  tasks  that  lend  themselves  more 
to  one  means  of  support  than  the  other. 

7.4.1  Operational  Hardware 

Operational  hardware  consists  of  those  aircraft  LRU's  that  are 
used  in  the  AISF.  The  suggested  method  to  have  these  LRU's  maintained 
would  be  to  treat  the  AISF  as  if  it  were  another  aircraft  so  that  LRU's 
could  be  replaced  through  normal  maintenance  channels.  In  addition  to 
this,  if  the  repair  facility  is  at  the  same  ALC  as  the  AISF,  an  agreement 
should  be  made  to  check  the  LRU  to  ensure  that  it  is  actually  bad  before 
it  is  placed  in  the  maintenance  pipeline.  This  helps  ensure  that  the  prob¬ 
lem  is  in  the  LRU  and  not  elsewhere  in  the  particular  test  stand. 

7.4.2  Commercial  Software 

Commercial  software  consists  of  software  (e.  g.  ,  operating  systems, 
compilers)  that  is  purchased  from  a  vendor.  This  software  is  best  main¬ 
tained  by  the  vendor  because  applications  programmers  generally  use  it 
as  a  tool  and  don't  become  familiar  enough  with  the  software  to  adequately 
maintain  it.  The  people  responsible  for  the  AISF  must  determine  the 
impacts  of  updating  commercial  software  on  the  applications  modules 
already  in  use. 

7.4.3  Applications  Software 

The  applications  software  is  that  software  which  has  been  written 
to  drive  the  test  stand  (e.  g.  ,  simulation  modules,  interface  drivers, 
data  reduction,  etc.  ).  It  should  be  maintained  organically  or  by  a  resi¬ 
dent  contractor  (i.  e.  ,  not  a  vendor  that  comes  on  call).  The  reason  for 
this  is  that  applications  software  tends  to  be  specialized  and  requires 
people  that  are  intimately  familiar  with  the  software  to  change  it. 

7-18 


Commercial  hardware  is  computers  and  off  the  shelf  equipment. 
Computers  are  usually  best  maintained  by  the  vendor  at  the  location  of  the 
AISF.  Some  of  the  other  commercial  hardware  does  not  have  repair  pro¬ 
cedures  set  up  like  most  computers  do.  In  this  case,  spares  must  be 
bought  to  keep  the  AISF  running  while  the  bad  unit  is  sent  for  repairs. 
Maintenance  of  all  commercial  hardware  should  be  considered  before  it 
is  purchased. 

7.  4.  5  Peculiar  Hardware 

Peculiar  hardware  is  designed  for  a  specific  test  stand  for  purposes 
such  as  special  interfaces  and  computer  monitor  equipment.  Spare  cir¬ 
cuit  boards  need  to  be  maintained  locally  for  all  peculiar  hardware.  This 
enables  a  bad  board  to  be  replaced  and  the  test  to  be  completed.  The 
troubleshooting  of  the  bad  board  can  be  done  without  impacting  the  test. 

This  repair  could  be  performed  by  organic  or  resident  contractor  tech¬ 
nicians,  when  not  modifying  the  test  stands  or  repairing  them,  could  serve 
as  test  stand  operators. 

7.5  CONCLUSIONS 

Facility  maintenance  is  important  enough  to  the  long  term  goal  of 
the  AISF  that  it  should  be  considered  during  the  design  phase.  If  it  isn't 
clear  that  adequate  support  can  be  obtained  for  any  given  hardware  or 
software,  an  alternative  design  should  be  used.  The  means  of  maintenance 
will  be  determined  by  factors  other  than  just  the  act  of  maintaining  hard¬ 
ware  or  software.  Some  of  these  factors  are  availability  of  slots,  people, 
and  money. 

Table  7-2  provides  the  recommended  means  of  maintaining  the  AISF. 
In  the  case  where  organic/contractor  is  used,  it  is  assumed  that  either 
can  perform  the  maintenance  equally  well  and  that  other  factors  will  deter¬ 
mine  which  one  would  perform  the  maintenance. 

7.6  RECOMMENDATIONS 

1.  Develop  a  coordinated  set  of  AFLC/AF SC  guidelines  for 
establishing  and  maintaining  post-deployment  software 
support  facilities.  These  guidelines  should  address  the 
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Table  7-2.  AISF  Maintenance  Responsibilities 


Function 

—  --  !  ' 

Responsible  Group 

Operational  hardware 

Commercial  software 

Applications  software 

Commercial  hardware 

Peculiar  hardware 

Organic /standard  repair  pipeline 
Contractor/commercial  vendor 

O rganic /contractor  (resident) 

Contractor /commercial  vendor  if  possible 
Organic/contractor  (resident) 
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gamut  of  planning,  development,  integration,  demonstra¬ 
tion,  and  maintenance  activities  as  well  as  documentation 
requirements  necessary  to  ensure  that  a  timely,  effective, 
and  efficient  capability  results.  The  Software  Acquisition 
Engineering  Guidebook  for  Software  Development  and  Sup¬ 
port  Facilities  recently  developed  for  ASD  provides  a  solid 
basis  for  such  guidelines. 

2.  Insist  that  a  support  facility  concept  and  requirements 
study  be  performed  during  the  conceptual/ validation  phases 
of  each  major  program  where  embedded  computer  resources 
are  involved  to  establish  the  support  concepts  and  tradeoffs 
which  need  to  be  considered.  This  action,  which  should  be 
under  the  advocacy  and  implementation  of  AFALD  with  close 
interaction  with  and  support  from  AFLC/LOEC  and  the 
ALC's,  should  be  fully  coordinated  with/approved  by  all 
MAJCOMS  and  interservice  agencies  involved. 

3.  As  recommended  in  Section  3.  3,  take  action  to  establish 
the  CRISP  as  a  USAF-wide  MOA  for  post- deployment  ECS 
resources  (viz.  support  facilities).  It  is  suggested  that  a 
request  be  submitted  to  the  JLC  to  establish  a  joint  panel 
to  assess  the  appropriateness  of  this  recommendation. 

4.  Modify  AFR  800-14  and  other  appropriate  guidance  to  more 
clearly  identify  the  funding  responsibilities  associated  with 
post-deployment  software  support  facility  acquisition  and 
O&M. 

5.  Develop  a  PMD/PMP/ILSP  checklist  which  can  be  used  by 
HQ  USAF,  AFLC,  AFALD,  and  field  agencies  participating 
in  ECS  acquisition  to  ensure  that  these  documents  properly 
address  support  facilities.  USAF/LEOC  should  be  encour¬ 
aged  to  non-concur  on  all  PMD's  which  do  not  adequately 
address  post-PMRT  support  facilities. 

6.  Incorporate  facility  planning  and  funding  as  part  of  the 
DSARC  process  —  including  these  as  specific  items  in  the 
"DOD  Embedded  Computer  Resources  and  DSARC  Process 
Guidebook.  " 

7.  In  concert  with  recommendations  tendered  in  Section  9.3, 
software  support  facilities  should  be  established  within 
AFLC  as  early  as  possible  in  the  acquisition  cycle  to 
capitalize  on  the  benefits  of  permitting  AFLC  to  carry  out 
pre-deployment  activities. 
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8.  FUNDING 


8.  1  BACKGROUND 

The  change  in  AFLC  role  and  the  necessity  to  shift  priorities 
toward  more  technological  and  mission-oriented  support  postures  have 
caused  some  perturbations  on  funding  levels  and  distribution.  This 
appears  to  be  due,  in  part,  to  the  lack  of  awareness  of  the  ECS  role  and 
the  basic  lack  of  understanding  of  the  nature  of  the  engineering  on  the 
part  of  all  level®  of  management  and  fiscal  organizations.  In  addition, 
the  multitude  of  fund  types  and  the  timeliness  of  establishing  funding 
requirements  for  software  engineering  place  an  undue  burden  on  the  ECS 
manager  in  planning  funding  channels.  The  POM/OOB  and  EOP/AEP/ 

CEP  cycles  demand  a  two-year  cycle  for  funding  definitions  by  category 
(Section  8.4)  while  ECS  support  is  mission  responsive,  necessitating  early 
estimates  of  the  amount  a<vJ  type  ^f  change  activity  to  flight  software. 

Two  other  ECS  areas  great'v  affected  are  training  and  travel  funds.  For 
both  of  these  categorit  s,  app  ->priations  not  related  directly  to  ECS  have 
lower  priority  than  other  elements  (MFP  VIII  category),  leading  to  the 
probability  that  the  rest  rtf  the  requirements  may  get  funded,  but  not 
training  and  travel  (i.  e.  ,  travel  and  subsistence  funds  are  in  perennial 
shortage  at  the  ALC's).  As  a  result,  personnel  who  will  be  responsible 
for  support  of  a  new  system  cannot  attend  design  reviews,  program 
reviews,  and  other  important  meetings  at  which  decisions  are  made  that 
affect  the  support  requirements.  Attendance  at  these  meetings  is  spelled 
out  in  AFR  800-14,  and  failure  to  accomplish  these  requirements  mini¬ 
mizes  front  end  costs  and  impacts  on  LCC. 

8.2  DISCUSSION 

While  this  section  treats  funding  as  an  issue,  it  is  in  part  only  symp¬ 
tomatic  of  other  issues  such  as: 

•  Facility  planning/acquisition 

•  Early  involvement  in  the  development/acquisition  process 

•  Flexible  response  to  software  changes 

•  Training 
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Another  concern  expressed  by  the  ECS  manager  was  split  funding 
which  will  also  be  addressed.  A  federal  budget  cycle  and  an  MCP  cycle 
are  included  for  reference. 

8.  2.  1  Facility  Planning /Acquisition 

Traditionally,  it  is  the  responsibility  of  the  implementing  command 
to  provide  for  support  facilities  along  with  weapon  system  development 
and  acquisition.  This  is  currently  done  adequately  for  all  traditional  types 
of  support  (ATE,  engines,  test,  TRC,  etc.),  and  although  the  requirement 
to  provide  software  engineering  support  facilities  is  clear  in  existing 
directives  (DODD  5000.29,  AFR  800-14),  confusion  still  exists  as  to  who 
will  fund  the  facility.  This  is  not  a  problem  with  all  systems.  For 
instance,  little  resistance  was  met  in  getting  the  F-15  and  F-16  SPO's  to 
meet  this  obligation;  however,  for  a  multitude  of  reasons,  the  E-3A  AISF 
planning  has  been  hampered/delayed  because  of  misunderstandings/ 
disagreements  in  this  area  (see  Section  7). 

Another  facet  of  this  problem  is  the  necessity  to  establish  facilities 
that  are  to  be  used  for  multi- system  support.  When  a  facility  is  devel¬ 
oped  for  the  unique  support  of  one  weapon  system,  it  is  clearly  stated  in 
AFLCR  800-21  that  the  individual  SPO  will  fund  the  effort  and  the  type  of 
funds  are  clearly  defined  in  AFM  172-1  (3010,  3020).  When  the  facility 
is  multi-purpose,  the  type  of  funds  is  clear  (3080);  however,  ECS  man¬ 
agers  expressed  concern  over  the  justification  and  approval  path,  or  who 
was  responsible  for  providing  the  funding.  Because  AFLC  does  not 
expend  funds  prior  to  PMRT,  it  would  appear  difficult  to  establish  con¬ 
solidated  support  concepts  prior  to  PMRT,  contrary  to  prudent  fiscal 
management.  Clearer  guidance  is  needed  in  the  area. 

As  stated  above,  funds  are  now  expected  to  be  provided  by  individ¬ 
ual  SPO's,*  however,  it  is  not  always  promptly  forthcoming.  The  time 
delay  in  convincing  an  SPO  that  the  AISF  is  a  real  requirement  to  be 
funded  out  of  its  already  depleted  funds  can  have  a  significant  impact  on 
the  timeliness  of  funding  and  therefore  the  operational  date  of  equipment. 

An  example  of  this  delay  can  be  seen  in  the  E-3A  program  where  the  SPO 
was  unconvinced  for  some  time  that  the  AISF  was  a  legitimate  requirement. 
Obviously,  if  AFR  800-14  stated  the  firm  requirement  that  software 
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support  equipment  was  to  be  funded  through  the  SPO  (it  is  certainly 
implicit)  and  the  weapon  systems  PMD  explicitly  called  for  its  funding 
and  support,  AFLC  planning  would  be  more  firm  and  programmable. 

This  should  also  be  made  a  part  of  the  DSARC  process  through  the  DCP; 
however,  this  would  lequire  a  modification  to  DODD  5000.  29. 

Another  problem  is  the  lack  of  a  link  between  weapon  system  modi¬ 
fication  and  support  facilities.  Often  a  modification  to  operational  hard¬ 
ware  is  approved  without  providing  for  the  updates  to  support  facilities, 
trainers,  etc.  ,  to  accommodate  the  change  (if  required).  For  example, 
funds  for  the  modification  of  the  F-15  AISF  due  to  the  programmable  sig¬ 
nal  processor  modification  were  not  automatically  provided,  although  the 
SPO  did  provide  the  funds  upon  request.  In  some  cases,  data  is  not  pro¬ 
cured  to  enable  the  support  facilities  to  be  provided  later  or  from  alterna¬ 
tive  funding  sources. 

8.  2.  2  Early  Involvement  in  the  Development/Acquisition  Process 

AFR  800-14  and  AFLC  implementing  directives  require  that  support 
agencies  (AFALD,  AFLC  HQ,  item/system  managers,  MMEC,  ACD, 
MA-T,  etc.  )  provide  inputs  to  the  development  and  acquisition  process 
beginning  with  the  conceptual  phase.  Travel  funds  are  stated  as  a  respon¬ 
sibility  of  the  particular  agency  through  normal  TDY  channels  (EEIC 
40  XX)  with  the  exception  of  Software  Support  Center  (SSC)  requirements 
which  will  be  program  funds.  The  problem  here  is  the  trend  toward 
reducing  TDY  expenditures  while  TDY  requirements  are  increasing  with 
the  increasing  ECS  workload.  In  the  light  of  congressional  ceilings  on 
travel  expenditures,  this  obviously  is  not  an  easy  issue  to  address.  How¬ 
ever,  since  directives  state  the  requirement  and  the  need  appears  to  be 
valid,  some  resolution  is  needed.  One  method  would  be  to  seek  approval 
for  ECS  related  TDY  to  be  funded  out  of  program  funds.  This  may  be 
justified  because  of  the  unique  nature  of  the  software  support  mission 
(more  direct  labor  than  overhead  oriented). 

8.  2.  3  Flexible  Response  to  Software  Changes 

The  real  issue  here  is  the  mission  related  nature  of  ECS  support. 
That  is,  the  requirement  to  accomplish  changes  to  a  degree  necessary  to 


meet  U.  S.  military  and  political  objectives,  rather  than  to  a  level  dic¬ 
tated  by  a  set  level  of  resources.  This  impacts  the  ability  of  the  ECS 
manager  to  accurately  predict  requirements  within  the  budgeting  cycle 
and  within  the  proper  budget  categories. 

The  ECS  manager  is  faced  with  supporting  mission  requirements 
with  preplanned  funding  which  may  or  may  not  be  the  right  type  or  be  suf¬ 
ficient  to  accomplish  required  activities.  For  instance,  software  change- 
only  funding  (EEIC  583-AA-JZ)  is  different  from  a  software  change  caused 
by  a  hardware  change  (EEIC  583  UA-ZZ).  Also,  the  hardware  modifica¬ 
tion  is  funded  under  a  different  budget  appropriation  (3010/3020/3080, 

BP  1100)  than  the  resulting  software  change.  This  brings  on  the  possi¬ 
bility  that  one  may  be  funded  and  the  other  declined  or  deferred.  Another 
complication  is  the  fact  that  3010  funds  are  three-year  funds,  while  EEIC 
583  funds  are  one-year  funds.  A  tremendous  boost  to  the  ECS  manager 
would  be  the  ability  to  expend  58  3  funds  over  three  years  concurrently 
with  hardware  funds  financing  the  same  activity.  This  would  also  negate 
the  precise  manner  which  the  ECS  manager  has  to  estimate  the  year  that 
funds  will  be  required.  Accurate  estimates  of  the  timing  of  software 
activities  related  to  hardware  modifications  can  be  difficult,  considering 
delays  in  modification  programs  brought  about  by  production  slips,  con¬ 
gressional  funding  limitations  for  hardware,  changing  requirements,  etc. 

Contributing  to  the  complications  associated  with  funding  appears 
to  be  a  general  misunderstanding  of  budget  categories,  qualifications  for, 
and  baselining  requirements.  Contributing  to  this  confusion  is  the  fact 
that  direction  is  in  several  documents,  letters,  etc.  Another  confusion 
factor  is  the  difference  and  timeline  between  ADPE  and  ECS  funding. 

Less  than  adequate  funds  are  generally  included  in  EEIC  583  due  to 
the  prevailing  concept  of  AFLC  in  the  stock-store-issue  business.  The 
concept  that  AFLC  is  in  the  digital  engineering  business  with  a  large  mis¬ 
sion  to  perform  must  be  reflected  in  funding.  One  of  the  primary  reflec¬ 
tions  of  the  lack  of  recognition  of  this  concept  is  the  difficulty  in  obtaining 
funds  by  the  ALC's.  It  would  probably  be  advantageous  to  conduct  an 
in-house  study  to  compare  costs  involved  in  performing  a  weapon  system 
modification  via  software  and  the  postulated  costs  for  performing  that 


same  modification  via  hardware.  This  data  could  then  be  used  to  justify 
additional  funds  to  support  ECS,  both  in  the  equipment/engineering  area 
and  in  the  TDY  area. 

Because  of  the  likelihood  that  less  than  full  funding  may  be  pro¬ 
vided  in  a  given  fiscal  year,  a  more  efficient  method  of  procurement  would 
allow  incremental  funding  of  contracts  for  development  of  support  tools. 
These  type  contracts  are  currently  not  in  widespread  use  within  the  AFLC 
and  are  restricted  by  regulation.  Recent  consideration  by  the  JLC 
brought  about  agreement  that  multi-year  procurement  to  include  incre¬ 
mental  funding  could  be  used  as  a  method  of  improving  buying  performance. 
While  no  specific  JLC  initiatives  are  known  at  this  time,  AFLC  should 
support  any  effort  to  encourage  DOD  and  Congress  to  ease  restrictions  to 
incremental  funding. 

Funding  avenues  for  IV&V  of  software  by  AFLC  are  not  well  defined. 
It  should  be  an  objective  of  AFLC  (recognized  in  AFLCR  800-12)  to  per¬ 
form  or  manage  IV&V  on  major  software  programs  developed  within 
AFSC  and  to  have  funding  for  this  activity  channeled  either  directly 
through  the  program  office  or  through  AFTEC  to  the  responsible  ALC. 

8.2.4  T  raining 

While  the  requirement  for  and  the  responsibility  to  provide  ECS 
training  is  well  documented,  examples  of  continuous  delays  are  encoun¬ 
tered  in  accomplishing  required  courses.  This  is  due  primarily  to  the 
perennial  shortage  of  funds  in  ATC  and  the  established  priorities.  The 
training  issue  is  treated  in  more  detail  in  Section  3  and  in  Volume  VIII 
of  this  report. 

8.  3  SPLIT  FUNDING 

In  the  case  of  concurrent  hardware/software  modifications  the  trend 
should  be  away  from  split  funding  for  engineering  change,  i.e.  ,  currently 
a  block  change  to  a  PROM-based  system  utilizing  on-site  contractor  per¬ 
sonnel  could  be  interpreted  to  require: 

•  BP  3400  EEIC  583  (AA  through  JZ)  for  software  changes 
not  related  to  hardware  changes  and  associated  CPIN 
data  packages. 


•  BP  3400  EEIC  583  (UA  through  ZZ)  for  software  changes 
related  to  hardware  changes  to  include  CPIN  data. 

•  BP  3400  EEIC  583  for  blank  PROM's. 

•  BP  2400  EEIC  594  for  TCTO's  to  announce  the  change  and 
support  affected  T.  O.  's. 

•  BP  3400  EEIC  569  to  maintain  the  AISF  equipment. 

•  BP  3400  EEIC  582  for  software  changes  for  general  pur¬ 
pose  ADPE  support  equipment  (i.  e.  ,  the  Univac  1108  at 
Warner  Robins). 

•  BP  3400  EEIC  568  for  maintenance  of  the  general  purpose 
machine. 

•  BP  3400  EEIC  592.63  for  subscription  services  for  any 
FSG  70  equipment. 

•  BP  3400  EEIC  92.  35  for  software  described  by  vendors 
in  subscription  services. 

•  Either  BP  3400  EEIC  54X  or  BP  4922  to  burn  and  install 
chips. 

These  procedures  are  further  complicated  if  any  rented  equipment 
is  used,  if  a  DAR  is  required  to  acquire  additional  equipment,  if  data 
items  require  printing,  or  if  a  modification  to  the  AISF  is  required. 

The  reduction  of  the  number  of  budget  categories  in  support  of  ECS 
support  would  reduce  the  uncertainty  and  difficulty  in  budgeting  funds. 

8.  3.  1  Federal  Budget  Cycle 

The  fiscal  year  budget  process  is  discussed  for  a  given  year  in 
very  broad  terms  in  order  to  obtain  an  insight  into  how  the  process  can 
affect  a  development  program.  The  current  process  is  based  on  the  Con¬ 
gressional  Budget  Reform  Act  of  1974  which  created  a  Congressional 
Budget  Office  (CBO)  which  services  both  Senate  and  House,  created  a 
committee  in  each  chamber  of  Congress  to  oversee  all  budget  functions, 
and  changed  the  FY  to  begin  1  October  rather  than  1  July. 

Using  FY82  budget  process  as  an  example,  the  process  event  dates 
are  shown  in  Figure  8-1  which  illustrates  three  principal  phases:  budget 
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Federal  Budget  Process  for  FY  82 


preparation  and  approval,  budget  Lmplementqtion,  and  budget  audit.  In 
the  following  discussion,  focus  will  be  made  of  the  budget  preparation 
and  approval  phase. 

The  FY82  process  starts  in  March  1980  when  the  Office  of  Manage¬ 
ment  and  Budget  (OMB),  which  is  responsible  to  the  President,  sends  a 
request  with  some  guidelines  to  each  agency  and  department  asking  that 
they  begin  submitting  FY82  budget  information  through  channels  to  OMB. 
This  requirement  is  filtered  down  to  the  lowest  levels  of  the  agencies  and 
departments  where  budget  planning  begins  with  estimates  made  and 
approval  sought  up  the  chain  of  command. 

On  10  November  1980,  the  President  submits  a  "Current  Services 
Budget"  to  Congress.  This  budget  indicates  the  estimated  cost  that 
would  incur  if  the  existing  services  were  to  continue  in  FY82  without 
change. 

In  January  1981,  the  President  presents  his  FY82  budget  documen¬ 
tation  which  has  been  gathered  and  massaged  by  each  level  up  the  ladder 
to  OMB.  This  budget  projects  increases  and  decreases  in  expenditures 
for  the  various  governmental  functions  and  services  and  estimates  incom¬ 
ing  revenues.  The  various  committees  in  the  Senate  and  the  House  (e.g.  , 
defense  committee,  agriculture  committee,  education  committee,  etc.  ) 
take  the  proposed  budget  and  evaluates  the  requirements  of  agencies 
within  their  area  of  assignment. 

By  15  March  1981,  these  various  committees  must  provide  gross 
estimates  of  funds  required  by  agencies  within  their  area  of  concern  to 
the  Budget  Committees  (one  in  Senate  and  one  in  House). 

By  15  April  1981,  the  two  Budget  Committees  must  draw  up  the 
first  Concurrent  Budget  Resolution  which  describes  the  projected  expendi¬ 
tures  and  revenues.  At  this  time,  the  sundry  congressional  committees 
begin  preparing  "authorization  bills"  which  will  authorize  agencies  to 
carry  out  functions  and  to  expend  funds  (although  funds  authorizations  are 
yet  to  come). 

By  15  May  1981,  all  authorization  bills  must  have  been  presented 
on  the  floor  and  Congress  as  a  whole  must  approve  the  first  Concurrent 
Budget  Resolution. 
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From  15  May  1981  to  August  1981,  the  Appropriations  Committee 
in  each  chamber  (but  primarily  in  the  House)  prepare  the  bills  to  appro¬ 
priate  funds  based  on  authorization  bills  and  compared  with  the  first  Con¬ 
current  Budget  Resolution.  During  this  period,  the  CBO  tracks  the  budget 
actions  and  compares  bills  for  expenditures  and  revenues  with  target 
funds  figures.  The  CBO  reports  to  Congress  each  week  on  the  amounts 
appearing  in  bills  versus  target  amounts. 

In  August  1978,  the  Budget  Committees  look  at  the  present  situa¬ 
tion,  derive  more  firm  figures,  and  prepare  the  second  Concurrent  Bud¬ 
get  Resolution. 

By  seven  days  after  Labor  Day,  Congress  must  have  finished  all 
appropriations  for  the  coming  fiscal  year. 

By  15  September  1978,  Congress  must  pass  the  second  Concurrent 
Budget  Resolution  and  ensure  that  all  appropriation  and  tax  bills  conform 
to  the  resolution.  Once  this  resolution  is  passed.  Congress  cannot 
increase  or  decrease  spending  on  tax  bills  unless  the  changes  retain  the 
same  total  deficit  balance  shown  in  the  resolution. 

The  final  accounting  to  ensure  that  the  bills  conform  to  the  resolu¬ 
tion  is  in  the  form  of  a  reconciliation  bill  passed  by  25  September.  This 
reconciles  the  tax  and  expenditure  bills  such  that  conformance  is  attained. 

On  1  October  1981,  the  FY82  begins  and  the  implementation  phase 
begins  lasting  through  30  September  1982. 

It  can  be  seen  that  if  funds  are  to  be  obtained  for  any  facility  func¬ 
tion  for  FY82,  the  requests  must  be  in  the  command  budget  estimates 
between  March  and  August  1980.  This  means  that  plans  must  be  firm 
1-1/4  years  prior  to  fund  implementation.  If  approval  is  not  obtained  in 
time,  another  year  can  be  lost  waiting  for  the  next  cycle. 

8.3.2  Military  Construction  Program  Cycles 

The  Military  Construction  Program  (MCP)  for  the  facility  (brick 
and  mortar)  programming,  design/construction,  initial  outfitting  equip¬ 
ment  funding,  etc.  is  a  long,  time  consuming  process  which  must  be  con¬ 
sidered  as  part  of  the  AISF  planning  process.  AFLC  Regulation  78-4 
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establishes  procedures  to  be  followed  in  the  acquisition  management.  As 
the  regulation  provides  details  on  the  schedules,  only  a  summary  highlight 
of  the  MCP  cycle  will  be  described  here. 

The  facility  programming,  design,  and  construction  along  with  the 
outfitting  of  the  building  with  a  mechanized  materials  handling  system  (if 
required)  and  initial  outfitting  equipment,  require  a  concerted  effort  of 
phasing  the  various  aspects  so  that  unnecessary  delays  do  not  occur. 

Since  funds  request  is  tied  to  the  federal  budget  cycle,  a  one  year  slip 
can  easily  occu.  if  an  important  deadline  is  not  met.  Figure  8-2  shows 
the  important  decision  points  as  well  as  the  phasing  of  the  facility  pro¬ 
gramming  steps  with  the  facility  design/construction  steps  so  that  the 
construction  can  proceed  as  soon  as  the  funds  are  approved.  The  steps 
are  briefly  described  in  the  following.  The  FY82  MCP  cycle  (funds  ready 
for  use  in  FY82)  is  taken  as  an  example. 

A.  Facility  Programming 

Al.  The  FY82  process  starts  in  October  1979  when  the  in-year 
program  portion  of  the  Five  Year  Defense  Plan  (FYDP)  is 
returned  to  HQ  AFLC/DEP  by  HQ  USAF/PREP.  This  pro¬ 
gram  is  passed  on  to  the  centers,  with  guidance  for  initial 
tasking  of  preliminary  planning  and  project  development. 

A2.  In  January  1980,  HQ  USAF/PREP  provides  detailed  MCP 

guidance  to  HA  AFLC/DEP,  which  in  turn  is  provided  to  the 
centers. 

A3.  In  January /February  1980,  the  Center  Facility  Board  con¬ 
venes  to  confirm  the  in-year  MCP  projects  and  priorities. 

The  out-year  priorities  are  also  developed. 

A4.  In  February  1980,  the  programming  documents  (DD  Forms 
139 1/139 1C)  and  the  project  priority  listing  are  submitted 
to  HQ  AFLC/DEP. 

A5.  In  March  1980,  HQ  AFLC  Facility  Panel  develops  the  inte¬ 
grated  project  priorities. 

A6.  In  April  1980,  the  HQ  AFLC  Facilities  Council  convenes  to 
consider  the  integrated  project  priorities. 

A7.  On  1  May  1980,  the  in-year  MCP  submittal  is  due  at  HQ 
USAF/PREP. 


8-10 


7779  I  FY  80  |  FV  81 _ 1  E  Y  82 


8-11 


Figure  8-2.  MCP  Cycles 


A8.  In  June  through  August  time  frame,  Air  Staff  meetings  are 

held  to  review  and  validate  program  content.  HQ  USAF  Facil¬ 
ities  Requirements  Committee  (FRC)  confirms  and  finalizes 
Air  Force-wide  in-year  MCP  submittal. 

A9.  On  1  October  1980,  the  Air  Force  in-year  MCP  is  due  at  the 
Office  of  Secretary  of  Defense  (OSD). 

A10.  In  October  1980,  OSD/OMB  Hearings  are  held. 

All.  In  November /December  1980,  the  OSD/OMB  Program  Budget 
Decision  (PBD)  cycle  takes  place. 

A 12.  In  January  1981,  the  in-year  MCP  is  submitted  to  Congress. 

A13.  In  July  through  September  time  frame,  final  Congressional 
action  and  Presidential  approval  takes  place. 

A 14.  On  1  October  1981,  the  FY82  in-year  MCP  funds  are  available 
for  apportionment. 

Facility  Design/Construction 

Bl.  In  December  1979,  development  of  project  books  is  initiated 
by  the  Base  Civil  Engineering  for  each  project  in  the  MCP. 

The  project  books  are  reviewed  and  coordinated  by  the  user 
and  support  offices. 

B2.  In  March  1980,  the  project  books  are  forwarded  to  HQ  AFLC/ 
DEE  for  review  and  approval. 

B3.  In  May  1980,  the  project  books  are  forwarded  to  HQ  USAF/ 
PRE  for  their  cursory  review. 

B4.  In  late  May  1980,  HQ  USAF/PREE  issues  the  Design  Instruc¬ 
tions  (DI)  to  the  appropriate  Air  Force  Regional  Civil  Engineer 
(AFRCE).  The  DI  identifies  the  design  agent;  USAF  approved 
project  scope,  and  programmed  amount. 

B5.  In  August  1980,  the  design  agent  (normally  the  Corps  of  Engi¬ 
neers)  negotiates  and  secures  the  services  of  an  architect- 
engineer  (A-E)  firm  (if  in-house  support  not  available). 

B6.  In  September  1980,  the  facility  design  is  initiated  by  the 
architect-engineer  firm. 

B7.  In  March  1981,  upon  35  percent  of  design  completion  (early 
preliminary  design)  a  design  review  is  held  to  review  the 
design  documents  (drawings,  specifications,  analysis,  cost 
estimates,  etc.). 


B8.  Tn  August  1981,  upon  95  percent  of  design  completion 
(unchecked  final  design),  a  design  review  is  held. 


B9.  In  September  1981,  the  Invitation  For  Bid  (IFB)  documents 
are  distributed  to  the  involved  AF  components  (Base  Civil 
Engineer,  AFLC,  and  user)  for  a  final  review.  This  review 
is  made  simultaneously  with  the  issuance  of  the  solicitation 
(advertisement  of  project). 

BIO.  In  November  1981,  sealed  bids  received  during  project  adver¬ 
tisement  period  are  publicly  opened  by  the  Contracting  Officer 
at  the  designated  time  and  place. 

Bll.  In  December  1981,  contract  award  is  made  provided  that 

specified  criteria  are  satisfied  (see  AFLCR  78-4  for  details). 

B12.  In  January  1982,  construction  period  begins. 

If  the  MCP  funds  are  to  be  available  for  FY82,  the  requirements  for 
the  facility  must  be  known  by  late  1979  or  almost  two  years  prior  to  funds 
availability.  Adding  the  construction  period  to  this  approval  period  can 
create  a  long  time  period  before  facility  completion.  Since  the  facility 
equipment  funds  are  approved  as  a  separate  package,  unnecessary  delays 
can  also  occur  and  add  complications  if  any  part  is  not  approved. 

8.4  RECOMMENDATIONS 

1.  Seek  approval  for  travel  to  AFR-800  required  meetings  to 
be  funded  through  program  funds  or  given  a  higher  prior¬ 
ity  within  BP  3400 /EEIC  40X. 

2.  Establish  definitive  funding  lines  within  AFR  800-14  and 
the  PMD's  to  route  facility  and  IV&V  funds  to  AFLC 
agencies  to  establish  support  capabilities. 

3.  Insist  on  full  funding  to  accomplish  the  AFLC  assigned 
mission  within  the  EEIC  583  line  and  justify  this  through 
an  in-house  hardware  versus  software  modification  cost 
comparison. 

4.  With  full  funding  within  EEIC  583,  reduce  the  split  funding 
now  inherent  in  the  software  block  change  concept. 

5.  Support  JLC  efforts  to  reduce  restrictions  to  multi-year 
contracts  to  include  incremental  funding. 

6.  Attempt  to  obtain  three-year  obligation  authority  for 
EEIC-583  funds. 

7.  Develop  a  comprehensive  set  of  funding  procedures  to 
include  any  of  the  above  alternatives  in  the  form  of  an 
AFLC  regulation  (AFLCR  800-21  now  attempts  to  do  this) 
and  keep  it  current  rather  than  dissiminating  direction 
through  letters,  etc. 
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9.  PRODUCT/DATA  QUALITY  AT  TRANSITION 


9.  1  BACKGROUND 

Product  quality  at  system  turnover  is  quite  like  the  weather:  every¬ 
one  talks  about  it,  but  no  one  seems  to  be  able  to  control  it.  AFLC  has 
initiated  several  major  undertakings  in  an  attempt  to  cope  with  this  issue. 
The  single  most  significant  undertaking  has  been  the  establishment  of 
AFALD;  however,  other  efforts,  such  as  advocating  changes  to  ASPR's 
and  updates  to  quality  assurance  standards  (MIL-STD  52779),  were 
directed  to  this  end.  And,  certainly,  progress  has  been  made.  However, 
software  continues  to  be  transitioned  that  has  not  been  thoroughly  tested, 
is  without  adequate  data,  and/or  without  adequate  support  tools  established 
to  carry  out  the  AFLC  mission.  The  intent  of  this  investigation  was  not 
to  assess  the  operational  suitability  of  the  delivered  system,  but  to  assess 
the  supportability  of  the  software  in  the  system,  delivered  for  organic 
support. 

9.2  DISCUSSION 

Elements  contributing  to  the  supportability  of  software  delivered 
include,  but  are  not  limited  to,  the  following: 

•  Standardized  languages 

•  Data  provided  on  software/systems 

•  Availability  of  support  tools 

•  Standardization  and  commonality  considerations 

•  Growth  potential  in  the  target  computer 

•  Completeness  of  development  (baseline) 

•  Demonstration  of  support  capability 

Consideration  of  these  elements  was  made  to  (1)  determine  the  extent  the 
element  currently  degrades  from  supportability  and  (2)  investigate  any 
other  method  for  improving  product/data  quality  over  and  above  those 
actions  currently  underway.  One  factor  affecting  all  these  elements 
which  would  appear  to  have  a  major  impact  on  this  area  is  the  timing  of 
AFLC  support  requirements.  This  will  be  treated  as  a  separate  issue. 


9.2.1  Standardized  Languages 


DODD  5000.  29,  5000.  29X,  5000.  30,  and  5000.  31  all  establish  the 
need  for  and  direction  in  the  use  of  standard  and  High  Order  Languages 
(HOL)  in  Embedded  Computer  Systems.  While  it  is  realized  that  this  is 
a  current  problem,  the  Air  Force  and  the  DOD  community  as  a  whole 
appear  to  be  making  substantial  progress  in  this  area.  This  subject  is 
also  discussed  in  Volume  VIII  of  this  report. 

9.2.2  Data  Provided  on  Software/Systems 

This  appears  to  be  the  second  most  pronounced  obstacle  to  organic 
support  (behind  manpower).  In  order  to  perform  transition  from  con¬ 
tractor  to  organic  software  support,  the  data  package  or  documentation 
is  the  necessary  vehicle  to  carry  the  body  of  knowledge  from  one  group 
to  another.  This  area  has  long  been  recognized  as  a  problem  area  in  the 
ECS  acquisition  process  with  (1)  the  data  packages  generally  incomplete, 

(2)  the  documentation  containing  numerous  inconsistencies/errors,  and 

(3)  data  withheld  because  of  proprietary  aspects.  Also,  some  data  appears 
to  be  deliberately  withheld  by  some  contractors  in  order  to  maintain  an 
advantage  in  possible  follow-up  business  opportunities. 

9.2.2.  1  Minimum  Data  Package 

AFLCR  800-21,  paragraph  l-19b,  describes  a  minimum  set  of  data 
required  for  software  support.  "System  specification"  should  be  added  to 
this  list.  Other  documents  which  should  be  considered  for  procurement 
are  facility  descriptions  used  in  the  development  and  planned  for  the  sup¬ 
port  phase. 

Although  a  minimum  data  requirements  list  exists,  one  problem 
is  that  the  procurer  has  no  standard  by  which  to  assess  what  should  con¬ 
stitute  the  content  of  a  minimum  data  package  necessary  for  performing 
software  support.  (Data  Item  Descriptions  are  not  standardized.)  Mili¬ 
tary  Standards  are  available  for  specifications  (MIL-STD  490,  483),  but 
other  standards  and/or  guidance  are  needed  for  the  other  documents. 

This  need  has  been  recognized  within  the  Air  Force,  and  steps  are 
currently  being  taken  as  evidenced  by  the  "Final  Report  of  the  Joint  Logis¬ 
tics  Commanders'  Software  Workshop",  dated  1  October  1979.  AFLC 
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headquarters  is  also  sponsoring  a  study  for  "Development  of  Joint  Ser¬ 
vices  Software  Acquisition  Documentation".  These  efforts  should  be 
strongly  pursued  as  the  need  definitely  exists. 

9.  2.  2.  2  Quality  at  Transition 

Even  if  the  desired  content  for  documentation  is  specified  carefully, 
errors/inconsistencies  occurring  at  management  responsibility  transition 
will  not  be  alleviated  unless  some  additional  strong  measures  are  taken. 
The  current  process  requires  transferring  the  responsibility  at  a  speci¬ 
fied  date  in  the  ECS  life  cycle  from  one  organization  to  another.  What 
assurances  should  the  latter  group  have  that  the  data  package  is  correct 
before  accepting  this  responsibility?  How  extensive  should  the  review 
process  be?  To  expect  that  a  documentation  review  can  be  performed  in 
a  short  period  of  time  before  PMRT  is  unrealistic.  The  amount  of  docu¬ 
mentation  for  complex  weapon  systems  is  overwhelming,  especially  if  no 
distinction  is  made  between  primary  and  secondary  documentation.  For 
example,  the  E-3A  specifications  assimulated  so  far  occupy  more  than 
28  feet  of  bookshelf  space. 

For  the  most  part,  reviews  consist  of  (1)  providing  the  reviewer 
with  the  document  approximately  one  month  ahead  of  the  review,  and  (2) 
spending  a  day  or  two  at  the  review  discussing  errors /inconsistencies. 

All  too  often,  discussions  center  around  superficial  problems,  such  as 
notations,  formats,  and  typographical  errors.  No  meaningful  effort  is 
made  to  correct  any  technical  errors  and  inconsistencies. 

The  contention  is  that  additional  measures  must  be  taken  if  the  qual¬ 
ity  of  documentation  is  to  be  improved.  The  required  in-depth  understand¬ 
ing  of  the  documentation  cannot  be  obtained  "overnight".  Even  if  the 
documentation  is  provided  earlier,  simply  reading  the  document  over  and 
over  will  not  achieve  the  necessary  level  of  understanding.  The  recom¬ 
mended  approach  is  that  the  group  to  be  given  the  eventual  responsibility  be 
required  to  perform  Independent  Verification  and  Validation  (IV&V)  during 
Full-Scale  Engineering  Development  (FSED).  This  IV&V  will  provide 
(1)  a  vehicle  for  the  O&S  personnel  to  gain  in-depth  understanding  of  the 
ECS  to  properly  review  and  accept  the  data  package  at  PMRT,  and  (2)  the 
method  successfully  used  in  important  programs  for  flushing  out  software 
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problems.  Instead  of  completely  depending  on  another  contractor.  Govern 
ment  employees  can  be  utilized  in  the  I V&V  process.  An  additional  payoff 
is  thereby  realized  with  little  change  in  overall  costs. 

9. 2. 2.  3  Independent  Verification  and  Validation  (IV&V) 

The  following  are  activities  which  would  be  beneficial  for  the  desig¬ 
nated  support  agency  to  accomplish  during  IV&V: 

System  Specification  Verification 

•  V &V  planning 

•  Requirements  analysis 

•  Documentation  review 
Tool  Development  and  Maintenance 

•  Tool  evaluation 

•  Tool  development 

•  Installation  and  demonstration 

•  Training 

•  Tool  maintenance 
Software  Requirements  Verification 

•  Requirements  analysis 

•  Critical  requirements  identification 

•  Documentation  review 
Software  Design  Verification 

•  Design  analysis 

•  Performance  analysis 

•  Documentation  review 
Program  Verification 

•  Code  analysis 

•  Machine  level  testing 

• 


Documentation  review 


Software  Verification 


•  Formal  testing 

•  DT&E  review 

•  Documentation  review 
Special  Studies 

•  Quick  turn-around  studies 

•  Design  analysis  trades 
Configuration  and  Data  Management  Support 

•  Configuration  management 

•  Data  management 

9-2. 2. 4  Proprietary  Implications 

The  contractor's  claim  to  proprietary  data  can  severely  impact,  if 
not  negate,  any  attempt  to  establish  an  organic  support  capability.  Impli¬ 
cations  are  that  the  segment  of  the  software  which  is  proprietary  must  be 
supported  by  the  contractor  throughout  its  life  cycle.  The  organization 
which  has  the  responsibility  over  the  total  system  is  denied  the  opportun¬ 
ity  to  understand  a  segment  of  the  system  (although  the  Government  is  not 
a  competitor,  other  contractors  may  be  used  during  organic  support). 

Often,  proprietary  claims  are  made  late  in  the  development  cycle 
when  it  is  difficult  to  rectify  the  problem.  Requirements  must  be  stated 
early  so  that  proprietary  implications  are  visible  at  source  selection  and 
may  be  worked  in  a  competitive  environment.  The  only  claim  which  can 
be  allowed  is  for  those  segments  developed  by  the  contractor  using  inde¬ 
pendent  research  and  development  funds.  (All  software  developed  with 
Government  funds  legally  cannot  be  proprietary.  )  Whenever  ECS  procure¬ 
ments  are  made,  there  should  be  a  stipulation  that  if  proprietary  software 
is  to  be  used,  it  must  be  identified  in  the  proposal.  There  shov’d  also  be 
stipulations  that  the  contract  to  be  negotiated  will  provide  the  Government 
the  opportunity  to  acquire  the  proprietary  data  at  a  specified  future  date. 
Whenever  selection  of  the  winner  is  made,  proprietary  data  aspects  should 
be  an  important  negative  factor  in  the  selection.  If  the  contractor  wishes 
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to  bring  in  proprietary  data  during  the  development  phase,  he  should  be 
allowed  to  do  so  only  if  he  agrees  to  sell  the  data  to  the  Government  at  a 
specified  future  date.  The  goal  in  any  ECS  procurement  should  be  the 
elimination  of  proprietary  aspects  for  the  O&S  phase.  Most  of  these  con¬ 
siderations  are  covered  in  ASPR's. 

9.2.3  Availability  of  Support  Tools 

This  is  an  area  that  could  be  helped  by  the  performance  of  IV&V  by 
the  eventual  support  agency.  Numerous  problems  in  this  regard  have  been 
successfully,  but  painfully,  worked  by  AFLC  organizations  in  the  past 
(F-15  Radar  Data  Processor  Assembler,  various  ATLAS  compilers,  and 
test  pattern  generators);  however,  early  involvement  would  preclude  any 
surprises  at  PMRT.  The  IV&V  process  itself  normally  provides  an  addi¬ 
tional  alternative  set  of  tools  for  support. 

9.2.4  Standardization  and  Commonality  Considerations 
This  is  covered  in  Volume  VIII  of  this  report. 

9.2.5  Growth  Potential  in  the  Target  Computer 

This  has  been  a  problem  in  the  past  (F -111),  but  does  not  appear  to 
be  now.  In  discussions  with  ECS  managers,  no  one  brought  it  up  as  a 
major  problem  with  today's  systems. 

9.  2.  6  Completeness  of  Development  (Baseline) 

The  problem  here  manifests  itself  primarily  in  the  Electronic  War¬ 
fare  (EW)  subsystems  that  have  transitioned  (ALR-46  Series,  ALQ-131). 
AFLC  has  met  this  challenge  by  basically  adopting  an  SPO  concept  within 
WR-ALC/MMR.  It  is  not  anticipated  that  a  major  system  transfer  will 
present  a  problem,  except  in  the  area  of  concurrent  software  changes 
(contractor  on  residual  tasks,  AFLC  on  updates  cited  after  transition). 
These  problems  will  have  to  be  worked  on  an  individual  basis  by  a  transi¬ 
tional  working  group  and  by  DPML. 

9.2.7  Demonstration  of  Support  Capability 

Demonstrations  of  support  capabilities  for  some  support  systems 
have  been,  or  are  being,  planned  (F-15,  APR-38,  etc.).  This  concept 
could  be  universally  applied  in  conjunction  with  the  in-house  IV&V  effort 
suggested  above. 
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9.2.8  Timing  of  AFLC  Support  Requirements 

Current  acquisition  practices  used  by  the  Air  Force  require  that 
support  systems  be  firmly  identified  and  specified  concurrently  with  the 
weapon  system  requiring  the  support.  Existing  directives  (AFR  800-14, 
AFLCR  800-21)  provide  adequate  guidance  for  inputting  support  require¬ 
ments  into  the  development/acquisition  process. 

The  Department  of  Defense  is  the  agency  responsible  for  approving 
or  disapproving  any  Air  Force-submitted  request  for  a  new  operational 
capability.  Funding  for  acquisition  of  weapon  systems  to  include  any  sup¬ 
port  equipment  costs  is  Congressionally  controlled.  The  weapon  system 
acquisition  go-ahead  is  dependent  upon  the  budget  responsiveness  of  Con¬ 
gressional  agencies  and  the  target  budget  as  estimated  by  the  Air  Force 
for  any  Air  Force  acquisition.  Typically,  a  weapon  system  cost  is  pre¬ 
liminarily  estimated  and  all  or  some  portion  of  that  estimate  is  approved. 
As  the  weapon  system  design  and  ensuing  costs  are  solidified,  a  more 
accurate  cost  is  presented,  and  likely  approved,  and  thus  the  target 
weapon  system  cost  is  established.  Even  with  this  additional  solidifica¬ 
tion,  however,  some  cost  and  technical  risks  still  exist  with  the  acquisi¬ 
tion  of  the  basic  weapon  system. 

A  parallel  risk  exists  with  the  support  system  itself.  In  years  past, 
support  systems  were  simpler  and  relatively  less  expensive  compared  to 
today's  standards.  Weapon  systems  which  use  computers,  with  their 
attendant  software,  are  commonplace  and  require  sophisticated  support 
systems,  such  as  AISF's,  that  represent  a  sizeable  portion  of  the  total 
investment.  Since  both  weapon  systems  and  support  systems  are  com¬ 
plex  and  their  acquisition  contains  risk,  overruns  are  not  uncommon. 
Because  of  the  necessity  to  forecast  complete  system  acquisition  costs 
to  include  support  systems  and  equipment,  it  is  necessary  that  support 
systems  be  firmly  identified  in  the  early  stages  of  acquisition.  Further¬ 
more,  there  is  a  basic,  bonafide  attempt  to  stay  within  the  target  cost 
limit.  Any  cost  escalation  of  the  basic  weapon  system  is  typically  met, 
at  least  partically,  by  diverting  funds  originally  budgeted  for  support 
systems,  documentation,  or  weapon  system  quality  and  testing  in  an 
effort  not  to  raise  the  target  costs.  (Of  course,  if  the  escalation  is  large 
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enough,  there  is  little  recourse  but  to  ask  for  a  higher  target  cost). 
Acquisition  of  the  basic  weapon  system  is  paramount  in  the  acquisition 
emphasis;  thus  any  penalty  to  support  components,  from  a  program  man¬ 
ager's  viewpoint,  is  understandable. 

Typically,  AFLC  identification  of  support  requirements  is  initiated 
early  in  the  acquisition  cycle,  with  details  defined  in  incremental  updates 
as  the  weapon  system  materializes.  Unfortunately,  weapon  system  design 
solidification  is  not  until  the  Preliminary  Design  Review  (PDR),  or  later, 
by  which  time  the  target  costs  are  expected  to  be  fairly  accurate.  Sup¬ 
port  system  design  is  necessarily  vague  until  the  weapon  system  design  is 
frozen.  During  this  development  period  when  the  weapon  system  is  evolv¬ 
ing,  rationale  for  defending  specific  dollar  amounts  for  the  support  system 
is  weak  because  the  support  system  cannot  be  firmly  specified.  Diverting 
funds  that  were  originally  planned  for  support  system  costs  makes  sense 
to  the  program  manager  because  (1)  the  support  system  is  not  firm  and 
the  defending  rationale  is  weak,  and  (2)  it  is  easier  and  less  volatile  to 
divert  funds  from  "inside"  the  weapon  system  acquisition  project  than  to 
defend  an  overrun  to  Congressional  agencies. 

This  diversion  indicates  that  AFLC  support  system  quality  is  at  the 
mercy  of  the  acquisition  process  itself.  While  directives  provide  ample 
policy/guidance  for  life  cycle  cost  considerations,  costs  and  schedules 
may  actually  drive  the  entire  weapon  system  acquisition  process  while 
life  cycle  costs  are  monitored.  Unfortunately,  it  is  very  difficult  to  quan¬ 
tify  the  impact  of  shortcutting  systems  testing,  documentation,  or  support 
system  quality  upon  total  life  cycle  costs.  The  impact  manifests  itself  to 
AFLC  when  operational  support  of  the  weapon  system  is  required  with 
documentation  which  must  be  updated  or  endured,  untested  deficiencies 
which  must  be  corrected,  and  poor  quality  support  systems  which  must 
be  improved  or  used  "as  is".  On  the  other  hand,  it  would  do  no  good  to 
have  a  quality  support  system  to  support  a  nonquality  system;  thus  this 
discussion  does  not  dispute  the  acquisition  emphasis. 

The  position  that  a  support  system  is  inadequate  is  usually  accepted 
only  after  data  has  been  gathered  to  prove  the  inadequacy.  Data  of  this 
type  is  not  usually  available  until  some  sort  of  operational  capability  has 
been  attempted  and,  perhaps,  established.  Chances  are  that  PMRT 
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already  will  have  occurred  and  the  original  acquisition  agency  no  longer 
has  the  responsibility  to  acquire  the  support  system,  so  any  updates  to 
the  support  system  must  be  done  by  AFLC. 

In  summary,  the  problem  is  that  acquisition  emphasis  can  cause 
inadequate  support  system  quality  which  impacts  AFLC  support  posture 
for  embedded  computer  systems.  One  possible  solution  to  this  problem 
is  the  establishment  of  joint  AFSC/AFLC  regulatory  guidance  that 
requires  the  approval  of  AFLC  prior  to  diversion  of  funds  programmed 
to  meet  AFLC  requirements.  {That  is,  leave  AFSC  responsible  for  the 
overall  acquisition,  to  include  the  support  system,  but  not  allow  support 
system  funds  to  be  spent  without  the  approval  of  AFLC.  )  Using  this 
approach,  the  support  system  quality  would  be  a  direct  responsibility  of 
AFLC  in  terms  of  requirements  definition  and  cost  control.  Any  weapon 
system  acquisition  overruns  would  be  the  responsibility  of  AFSC  and  any 
support  system  acquisition  overruns  would  be  the  responsibility  of  AFLC. 

9.  3  RECOMMENDATIONS 

1.  Develop  an  embedded  computer  resources  guidebook  which 
can  be  used  by  source  selection  team  members.  Among 
other  AFLC  requirements  this  guidebook  should  delineate 
support  data  considerations  as  well  as  the  methodology  to 
be  used  in  developing  the  ECS  elements. 

2.  Update  the  minimum  set  of  data  requirements  listed  in 
AFLCR  800-21  to  include  a  system  specification  and  soft¬ 
ware  development /support  facility  description  documents. 

3.  Develop  content  standards  and/or  guidance  for  documents 
not  covered  under  MIL-STD  490  and  MIL-STD  483. 

4.  Provide  continued  AFLC  support  to  the  joint  services 
effort  aimed  at  defining  documentation  requirements  for 
software  acquisition. 

5.  Adopt  a  formalized  means  of  directly  and  actively  involv¬ 
ing  AFLC  in  the  ECS  acquisition  cycle  sufficiently  in 
advance  of  PMRT  to  ensure  a  high  quality  of  well  base¬ 
lined  software  and  related  documentation  exist  at  trans¬ 
fer  and  that  sufficient  resources  (personnel,  training, 
equipment,  facilities,  support  software,  etc.  )  are  timely 
made  available  to  AFLC  to  carry  out  life  cycle  O&S  soft¬ 
ware  support.  It  is  urged  that,  as  part  of  this  approach, 
AFLC  perform  predeployment  IV&V  on  development  soft¬ 
ware  and  demonstrate  AFLC  software  supportability  as  a 
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prerequisite  for  transfer.  These  provisions  should  be 
made  part  of  the  AFR  800-4  PMRT  plan. 

6.  Eliminate,  through  discrimination  in  the  source  selec¬ 
tion  process  and  through  contractual  terms  in  the  pro¬ 
duction  phase,  proprietary  software  which  is  either 
integral  to  or  used  in  support  of  a  USAF-maintained 
ECS. 

7.  Establish  joint  AFSC/AFLC  regulatory  guidance  that 
requires  AFLC  approval  prior  to  the  reprogramming 
funds  earmarked  for  AFLC  requirements  to  other 
acquisition  areas. 

8.  Continue  to  encourage  AFLC  participation  in  the  require¬ 
ments  definition  phase  of  the  acquisition  cycle  to  ensure 
adequate  resources  for  post-deployment  support  are 
defined  from  the  onset.  Measures  should  be  taken  at 
AFLC  HQ  to  make  available  sufficient  manpower  and 
skills  to  define  and  follow-up  these  requirements. 
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10.  MANAGEMENT  STRUCTURE 


10.  1  BACKGROUND 

Current  AFLC  management  structure  is  the  result  of  an  evolution 
spanning  several  years.  With  few  minor  exceptions,  the  structure  has 
not  significantly  considered  support  of  ECS  software  to  the  extent  of  influ¬ 
encing  the  structure  configuration.  That  is,  the  structure  was  configured 
to  provide  support  to  systems  and  items  with  primary  emphasis  on  the 
hardware  involved.  The  structure  was  further  designed  to  achieve  spare 
and  repair  support  without  extensive  regard  to  engineering  development. 

As  the  AFLC  role  in  engineering  development  has  changed  in  recent  years, 
particularly  in  regard  to  ECS  software  support,  certain  anomalies  have 
surfaced  within  the  AFLC  management  structure. 

Much  discussion  on  this  subject  and  numerous  alternatives  have 
evolved  in  the  past  few  years  directed  at  better  aligning  the  AFLC  struc¬ 
ture  to  meet  challenges  brought  about  by  this  new  role.  Because  it  would 
be  impossible  to  objectively  assess  the  numerous  organizational  interfaces 
involved  in  the  current  and  myriad  of  proposed  alignments,  this  section 
will  attempt  only  to  investigate  some  of  the  alternatives  and  provide 
insight  into  their  advantages  and  disadvantages.  Two  significant  organiza¬ 
tional  realignments  recently  have  been  accomplished  by  AFLC  which 
impact  embedded  computer  support.  These  are:  (1)  the  establishment  of 
AFALD,  and  (2)  the  establishment  of  an  Electronic  Warfare  (EW)  Manage¬ 
ment  Division  at  WR-ALC  (MMR).  Because  these  actions  are  relatively 
new  and  their  impact  is  difficult  to  assess,  no  suggested  changes  to  their 
organizational  arrangement  will  be  considered;  however,  it  is  strongly 
recommended  that  these  organizations  be  staffed  at  all  levels  (planning, 
acquisition,  management)  with  personnel  experienced  in  dealing  with  ECS 
problems,  with  strong  emphasis  on  engineering  disciplines. 

10.2  DISCUSSION 

Two  levels  of  management  will  be  discussed  as  they  pertain  to  ECS 
management.  These  are  the  HQ  and  the  ALC  structure.  Each  of  the 
organizational  alignments  investigated  will  be  presented  as  alternatives. 
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10.  2.  1  Headquarters  AFLC  Structure 

The  primary  agencies  within  AFLC  which  have  an  impact  on 
embedded  computer  support  are  LO,  XR,  MA,  and  AC.  LO  (LOEC)  is  the 
office  of  primary  responsibility  and,  therefore,  responsible  for  policy 
and  guidance  affecting  ECS.  AFLC  HQ  is  structured  along  functional 
lines  which  appears  a  reasonable  approach.  Then  the  question  may  be 
asked,  "Why  is  organizational  structure  an  issue?"  The  primary  com¬ 
plaints  heard  from  field  agencies  are: 

•  Policy  and  guidance  are  inadequate. 

•  Headquarters  does  not  understand  the  field's  problems. 

•  Responsibility  assignment  is  not  in  accordance  with  reg¬ 
ulations  or  good  management  practices. 

Because  these  complaints  span  several  offices,  let  us  look  at  the 
complaints. 

While  restructuring  may  offer  the  most  expeditious  means  of  reply¬ 
ing  to  these  complaints,  a  degree  of  relief  is  achievable  through  a  consci¬ 
entious  effort  to  more  closely  coordinate  activities  between  AFLC  HQ  and 
the  ALC's.  Regularly  scheduled  AFLC  in-house  status  reviews  (e.  g.  , 
semi-annually)  which  go  beyond  the  concerns  broached  in  the  Log  RCS 
reporting  system  are  suggested  as  an  intensive  alternative. 

10.2.  1.  1  Policy  and  Guidance 

The  complaint  here  is  more  accurately  stated  as  too  much  guidance. 
In  addition  to  DODD  5000.29,  AFR  800-14,  and  AFLC  implementing  regu¬ 
lations,  numerous  logistics  publications  (AFLCR  23-42,  23-43,  23-44, 
66-17,  66-27,  66-37,  67-17,  etc.),  data  processing  directives  (AFR  300 
Series),  and  funding  documents  (AFM  172-1,  etc.)  contain  guidance 
impacting  on  ECS  support.  There  is  some  validity  in  the  argument  that 
there  is  vaguely  stated  or  confusing  guidance;  however,  AFLCR  800-21, 
with  some  exceptions  (notably  ATE),  is  a  reasonable  attempt  at  stating 
policy  as  it  now  exists.  The  primary  problem  appears  not  to  be  in  dis¬ 
seminating  guidance,  but  in  obtaining  coordination  of  policy  within  the 
HQ  and  with  other  agencies.  This  is  primarily  due  to  parochial  consid¬ 
erations  and  cannot  be  resolved  by  this  report.  One  consideration  would 
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be  to  elevate  the  status  of  LOEC  to  a  three-letter  office  symbol;  however, 
since  software  engineering  is  a  subset  of  engineering  and  the  strong  need 
exists  to  maintain  a  systems  approach  to  engineering,  this  would  appear 
to  further  confuse  the  issue  by  separating  software  and  hardware  engineer¬ 
ing  aspects. 

10.2.1.2  Field  Problems 

Headquarters  does  not  understand  the  field's  problems.  Of  course, 
this  allegation  cannot  be  substantiated  or  denied.  The  fact  remains,  how¬ 
ever,  that  there  is  not  a  major  civilian  field  manager  from  within  the 
ALC's  (i.  e.  ,  MMEC)  directly  responsible  for  establishing  a  software 
support  posture,  that  has  progressed  to  a  Headquarters  assignment  in  a 
policy-making  position.  This  is  encouraged  to  offset  these  allegations. 

10.2.1.3  Responsibility  Assignment 

Responsibility  assignment  is  not  in  accordance  with  regulations  or 
good  management  practices.  By  mutual  consent  with  the  customer,  this 
issue  is  not  addressed  in  this  report. 

10*2.2  ALC  Structure 

In  considering  the  ALC  organizational  structure,  four  alternatives 
were  examined.  In  all  the  considerations,  no  structure  was  suggested 
that  would  require  shifting  any  workload  from  one  ALC  to  another.  Due 
to  the  emotional  facets  of  such  a  suggestion,  it  was  felt  it  would  detract 
from  the  study.  These  alternatives  are: 

•  Establish  a  management  division  for  each  avionics  (e.  g. , 
command  and  control)  type  of  FSC. 

•  Establish  a  service  engineering  organization  with  all 
digital  hardware  and  software  engineers. 

•  Establish  a  software  only  organization. 

•  Retain  present  structure. 

10.2.2.1  FSC  Management  Division 

This  approach  would  be  more  applicable  to  WR-ALC  because  of  its 
heavy  involvement  with  avionics  item  management,  but  would  be  some¬ 
what  applicable  to  all  ALC's.  It  is  along  the  lines  of  the  WR-ALC  MMR 
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organization.  The  approach  appears  to  be  working  well  for  MMR;  how¬ 
ever,  it  may  not  work  well  for  other  equipment  classes.  Advantages  are: 


•  Provides  for  a  system  engineering  approach  by  consolidat¬ 
ing  hardware  and  software  engineering. 

•  Provides  for  more  consolidation  of  like  activities  so  that 
more  standardization  of  tools  and  facilities  can  be 
implemented. 

•  Consolidates  expertise  for  a  particular  type  equipment. 

•  Collocates  engineering,  technician,  management,  and 
supply  activities. 

•  Could,  in  cases,  reduce  the  tools  available  to  the  system 
manager  to  fulfill  weapon  system  level  training. 

Disadvantages  are: 

•  Will  probably  impact  manpower  requirements  in  overhead 
positions. 

•  Dilutes  any  consolidated  core  of  software  expertise  now 
available  in  MMEC  organizations. 

10.2.2.2  Service  Engineering 

This  is  the  alternative  which  appears  to  most  nearly  implement 
AFR  800-14  from  a  centralized  engineering  management  standpoint.  This 
is  similar  to  the  old  service  engineering  concept  used  in  AFL.C  prior  to 
the  last  major  MM  reorganization.  The  advantages  are 

•  Affects  the  consolidation  of  digital  engineering  expertise. 

•  Collocates  all  digital  engineers  with  the  AISF. 

•  Establishes  a  total  digital  system  engineering  concept 
to  technical  problems. 

Disadvantage  is: 

•  Separates  engineering  from  supply  activites. 

10.2.2.3  Software  Only  Organizations 

This  alternative  was  considered  for  software  as  a  whole  and  for 
ATE  software  only. 


10.2.2.3.1  ATE  Software.  Advantages  are: 


•  Will  resolve  the  current  conflicts  over  organizational 
responsibilities. 

•  Will  probably  reduce  manpower  requirements  in  over¬ 
head  and  technical  areas. 

Disadvantage  is: 

•  Impairs  the  accessibility  to  equipment  now  enjoyed  by 
SSC  personnel. 

10.2.2.3  2  All  Software.  Advantages  are: 

•  Establishes  a  single  focal  point  for  software. 

•  Collocates  software  engineers  with  AISF. 

Disadvantages  are: 

•  Separates  software  and  hardware  engineering  and  thus 
impacts  the  system  engineering  aspects. 

•  Separates  SSC  activities  from  maintenance  equipment. 

10.2.2.4  Retain  Present  Structure 


Advantages  are: 

•  Current  policy /guidance  is  applicable  to  present  structure. 

•  Protects  against  the  uncertainty  that  would  accompany  an 
organizational  change. 

Disadvantages  are: 

•  Present  problems  will  persist  in  ATE  organizational 
responsibility  conflicts. 

•  Some  duplication  of  effort  is  evident  impacting  manpower. 

•  Competition  for  software  workload  and  resources  will  per¬ 
sist  between  organizations  involved  in  ECS  support. 

10.3  ALTERNATIVES 

•  Establish  a  management  division  for  each  avionics  type  or 
Federal  Supply  Class  at  the  ALC's. 

•  Establish  a  service  engineering  organization  with  all  digital 
hardware  and  software  engineers  at  each  ALC. 

•  Establish  a  software  only  organization  at  the  ALC's. 
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Table  A-  1.  Recommendations  Which  Can  Be  Implemented 
By  Directive  or  Direct  Management  Action 

•  Issue:  ECS  Readiness  Support  Concept 

•  Recommendations 

From  a  priority  ranking  of  avionics  systems.  Fire  Control 
Radars  and  their  associated  "core  of  trained  personnel" 
should  be  ranked  as  first  priority. 

Conduct  an  extensive  review  of  the  current  and  future  ALCs' 
mission  and  from  this,  document  their  requirement  for  the 
use  and  storage  of  classified  data  to  include  both  "Friendly/ 
Blue"  and  Foreign  Intelligence  Data.  WR-ALC  and  SM-ALC 
should  receive  first  priority  for  this  review  due  to  their 
extensive  work  in  the  area  of  electronic  warfare.  This 
should: 

a.  Identify  the  type  and  classification  of  the  various 
ALC  ECS  support  facilities  as  a  function  of  both  the 
classified  intelligence  material  handling/storage 
and  the  classified  nature  of  the  "Friendly/Blue" 
systems.  This  effort  should  include  not  only  a 
review  of  the  overall  facility  classification,  but 
also  identification  of  required  work  areas  and  con¬ 
ference  facilities, 

b.  Analyze  and  identify  the  type,  number  and  level  of 
classification  of  the  personnel  required  to  support 
each  ALC  in  this  area. 

c.  Document  and  implement  appropriate  HQ  AFLC 
direction  in  the  area  of  specific  responsibilities  for 
obtaining  and  providing  the  required  intelligence 
support  at  the  various  ALCs.  Specific  considera¬ 
tion  should  be  given  to  publication  of  an  AFLC 
implementation  regulation  for  AFR  200-1. 

d.  Based  upon  the  above  work,  develop  a  long-range 
plan  for  obtaining,  storing,  and  working  with  for¬ 
eign  intelligence  data  command- wide. 

Develop,  in  coordination  with  operational  commands  and  the 
intelligence  community,  a  concept  of  operations  for  repro¬ 
gramming  critical  mission  embedded  computer  systems. 

The  EWIR  concept  now  used  for  EW  reprogramming  should 
be  used  as  a  guide. 
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Issue:  Personnel  and  Training 
Recommendations 

a.  Develop,  within  guidance  provided  by  Headquarters 
AFLC  (e.g.,  via  AFLCR  800-21,  AFLCR  400-XX), 
detailing  of  the  various  support  concepts  and  alter¬ 
natives  —  and  accompanying  decision  rationale  — 
requisite  in  arriving  at  an  optimum  approach  (i.  e.  , 
a  more  detailed  version  of  the  logic  paths  sketched 
for  the  ALFC  GLDT  in  AFLCR  400-XX).  Included 
should  be  a  clear  breakout  of  governmental  and 
readiness  functions.  It  is  recommended  that  any 
organic  staffing  logic  used  by  based  upon  an  average 
employee  tenure  of  4-7  years  vs.  the  15-20  years 
usually  associated  with  government  employees. 

b.  Develop,  within  guidance  provided  by  HQ  AFLC, 
specific  guidance/AFLC  policy  regarding  the  con¬ 
solidation  of  resources  (including  cross-training) 
across  ALC's  and  ECS's. 

c.  Develop,  within  guidance  provided  by  HQ  AFLC,  a 
generic  breakout  of  functions  and  activities  required 
in  the  software  O&S  job  for  a  given  ECS  as  well  as 
for  a  multi-ECS  environment  (Reference  3-1  pro¬ 
vides  the  rudiments  for  such  a  breakout). 

d.  Develop,  within  guidance  provided  by  HQ  AFLC,  a 
skill  level  index  accompanying  position  descriptions, 
and  manpower  quantity  algorithm  which  tracks  with 
la  through  c  above. 

e.  Develop,  within  guidance  provided  by  HQ  AFLC  a 
step-by-step,  time-phased  trace  depicting  the  man¬ 
power  acquisition  (authorization)  process,  including 
new  starts  and  other  additive  elements,  as  well  as 

a  responsibility  breakdown  between  HQ  AFLC 
offices,  ALC  offices,  and  MES  Detachments.  Other 
manpower  exercises  which  are  conducted  but  not 
related  to  the  authorization  process  should  be  dis¬ 
cussed  for  information  purposes. 

f.  Develop,  within  guidance  provided  by  HQ  AFLC  an 
expansion  of  the  CRISP  content  to  include  contin¬ 
gency  planning  for  ECR's  in  the  event  manpower, 
funding,  MCP's  inherent  in  the  primary  support 
concept  are  delayed  or  denied. 


Table  A-l.  Recommendations  Which  Can  Be  Implemented  By- 

Directive  or  Direct  Management  Action  (Continued) 

•  Issue:  Personnel  and  Training  (Continued) 

•  Recommendations 

g.  Conduct  a  study  to  evaluate  traditional  support  roles 
and  missions  of  the  various  AFLC  organizations  (i.e., 
AC,  MMR,  MMEC,  MMET,  MA-T)  as  they  relate  to 
computer  resources,  including  the  matrix  manage¬ 
ment  concept  in  the  ALC's.  The  result  of  this  study 
should  be  a  work  breakdown  structure  for  the  job 
description  above. 

Clarify  and  definitize  in  USAF-level  guidance  (e.  g.  ,  AFR 
800-14),  the  roles  and  missions  of  the  using  command  and 
support  command  insofar  as  software  O&S  is  concerned. 

This  guidance  should  be  well  keyed  to  the  concepts  and 
alternatives  developed  above. 

On  the  basis  of  the  WBS  developed  above,  provide  guidance  to 
the  ALC  for  organizational  structure  in  MMEC  organization 
and  definition  of  interface  functions  within  the  MM-R,  MA-T, 
AC,  etc.  ,  organizations. 

Establish  through  channels,  a  means  to  provide  sufficient 
pre-PMRT  manpower  and  funding  for  post-deployment  pos¬ 
turing,  DTfeE,  IOT&E  support,  etc. 

Establish  recruiting  activity  within  each  ALC,  thus  reducing 
the  engineering  role  in  this  regard  to  one  of  conducting  tech¬ 
nical  interview  and  deciding  amongst  candidates.  Make  pro¬ 
visions  as  necessary  for  manpower  requirements  for  activity 
and  funds  for  TDY,  advertising,  etc. 

Replace  the  MES  Detachment  function  in  the  software  O&S 
manpower  authorization  loop  by  establishing  a  manpower 
screening  function  within  HQ  AFLC  LOE  to  approve  ALC 
software  O&S  ECR  requirements. 

Take  steps  to  have  software  manpower  removed  from  the 
"additive"  category  and  placed  in  the  manpower  baseline 

with  other  O&M  functions. 

* 

Take  action  through  HQ  USAF  to  establish  CRISP's  as  formal 
intra -command  MOA's  and  formal  instruments  of  approval 
for  ECR's. 

Continue  attempts  to  establish  special  categories  and  high 
grade  authorizations  for  software  engineers  (viz.  via  the 
Joint  Civilian  Personnel  Management  Group  studying  recruit¬ 
ment,  retention  and  utilization  of  engineers  and  the  Civil 
Service  Commission). 


Table  A-l.  Recommendations  Which  Can  Be  Implemented  By 

Directive  or  Direct  Management  Action  (Continued) 


•  Issue:  Personnel  and  Training  (Continued) 

•  Recommendations 

Establish  OPR's  for  ECS  software  O&S  training  at  HQ 
AFLC/LOE  and  at  each  ALC. 

Establish  in  HQ  AFLC/LOEC  a  special  position  (e.  g.  ,GS-14  or 
GS-15)  for  an  expert  in  ECS  O&S  who  has  first-hand  experi¬ 
ence  in  the  problems  confronted  by  ALC's.  This  position, 
which  might  be  rotational  in  nature,  should  be  filled  from 
the  ALC's.  The  chief  role  of  this  position  would  be  to 
advise  the  ALC's  on  their  problems  and  to  participate  in 
the  HQ  decision  process. 

Within  the  WBS  developed  above,  consider  adding  additional 
administrative  positions  for  absorbing  many  of  the  less  tech¬ 
nical  functions  now  carried  out  by  the  software  engineers. 

Encourage  rotation  of  key  personnel  across  ECS's  (and  even 
ALC's)  to  help  in  keeping  these  invaluable  resources  chal¬ 
lenged  as  well  as  to  accelerate  the  training  process  for  the 
more  junior  employees. 

Establish  a  more  structured  communications  loop  between 
HQ  and  the  ALC's  through  in-house  status /problem  reviews. 

•  Issue:  Microprocessors  and  Firmware  Support 

•  Recommendations 

Formulate  a  joint  AFSC/AFLC  regulation  concerning  micro¬ 
processors  and  firmware  definitions,  concept  of  operations, 
configuration  management  practices,  policies,  and  proce¬ 
dures.  This  should  include  policies  on  HOL's  and  data 
requirements  and  the  need  for  firmware  DID's. 

Provide  support  for  the  development  of  an  ADA  language  for 
microprocessors. 

Provide  guidance  for  the  incorporation  of  microprocessor 
and  firmware  implications  into  the  logistics  planning 
process. 

Insist  that  AFSC  provide  data  on  microprocessors  and  firm¬ 
ware,  sparing  requirements,  storage  environments,  shelf 
life,  and  parts  agreements. 
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Table  A-  1.  Recommendations  Which  Can  Be  Implemented  By 

Directive  or  Direct  Management  Action  (Continued) 

•  Issue:  AFR-800  vs.  AFR-300  Acquisition/Support 

•  Recommendations 

This  acquisition  issue  is  currently  being  worked  by  the 
Joint  Logistics  Commands;  therefore,  no  alternatives  are 
suggested  other  than  to  continue  support  of  the  JLC  initia¬ 
tives  toward  adoption  of  the  proposed  changes  to  DOD 
Directive  5000.  29. 

•  Issue:  Configuration  Management 

•  Recommendations 

Review  the  suitability  of  the  CPIN  system  for  controlling 
baselining  documentation  —  particularly  for  computer  pro¬ 
grams  employed  in  a  multi-version  environment  involving 
more  than  a  single  ECS  and  a  single  weapon  system. 

Reviev,  the  O/S  CMP  outline  recommended  in  AFLCR  800-21 
with  the  thought  of  reorienting  it  more  toward  specific, 
detailed  "procedures"  rather  than  toward  top  level  "plan¬ 
ning".  The  CRISP  CM  section  might  warrant  change  to  bet¬ 
ter  accommodate  the  CM  "planning"  aspects.  Consideration 
should  also  be  given  to  modifying  both  these  outlines  to 
accommodate  the  various  types  of  software  that  may  be 
addressed  in  a  weapon  system  level  O/S  CMP  (i.  e.  ,  OFP, 
ATE,  etc.  —  including  necessary  support  software). 

As  suggested  in  Personnel  and  Training,  formulate  a  gen¬ 
eric  set  of  software  change  activities  and  associated  O&S 
functions  which  are  applicable  across  the  five  ECS  types. 

The  CRISP  and  O/S  CMP  outlines  presented  in  AFLCR 
800-21  should  be  modified  to  reflect  this  partitioning.  The 
work  breakdown  structure  at  the  ALC's  should  also  be 
adjusted  to  be  more  closely  aligned  with  these  functions/ 
activities. 

Implement  the  recommendations  tendered  in  Product/Data 
Quality  at  Transition  to  assure  suitable  baseline  descrip¬ 
tions  are  available  at  ECS  PMRT  and  are  kept  current  (with 
respect  to  the  physical  media)  over  the  life  cycle. 

Through  close  coordination  with  AFSC,  encourage  the:  pre¬ 
deployment  use  of  the  procedure  format  evolving  from 
detailing  the  configuration  management  provided  in  AFR 
800-14  and  AFLCR  800-21  into  ALC  division  and  branch 
level  procedures  discussed  in  general  recommendations, 


Table  A-l.  Recommendations  Which  Can  Be  Implemented  By 

Directive  or  Direct  Management  Action  (Continued) 


•  Issue:  Configuration  Management 

•  Recommendations 

and  the  tools  selected  in  implementing  the  recommendations 
tendered  in  Product/Data  Quality  at  Transition  sited  above. 

Re-examine  the  requirements  set  forth  in  AFLCR  800-21 
and  66-15  regarding  the  use  of  Material  Deficiency  Reports 
(MDR's),  Materiel  Improvement  Projects  (MIP's)  and 
TCTO's  to  report,  track  and  release  ECS  software  changes. 

A  "tailored"  process  more  closely  attuned  to  the  software 
change  cycle  (for  emergency,  urgency,  routine  —  and  block 
change  concepts)  appears  in  order. 

Re-evaluate  the  manpower  and  staffing  plans  for  each  ECS 
currently  entering  the  inventory  to  assure  that  proper  CM 
resources  (tools,  personnel,  equipment  and  facilities)  are 
programmed.  Emphasize,  where  appropriate,  the  import 
of  effective  life  cycle  CM. 

Assure  that  the  training  planning  recommended  in  Person¬ 
nel  and  Training  adequately  addresses  CM  requirements. 

•  Issue:  Facility  Planning /Funding /Maintenance 

•  Recommendations 

Develop  a  coordinated  set  of  AFLC/AFSC  guidelines  for 
establishing  and  maintaining  post -deployment  software  sup¬ 
port  facilities.  These  guidelines  should  address  the  gamut 
of  planning,  development,  integration,  demonstration,  and 
maintenance  activities  as  well  as  documentation  requirements 
necessary  to  ensure  that  a  timely,  effective,  and  efficient 
capability  results.  The  Software  Acquisition  Engineering 
Guidebook  for  Software  Development  and  Support  Facilities 
recently  developed  for  ASD  provides  a  solid  basis  for  such 
guidelines. 

Insist  that  a  support  facility  concept  and  requirements  study 
be  performed  during  the  conceptual /validation  phases  of  each 
major  program  where  embedded  computer  resources  are 
involved  to  establish  the  support  concepts  and  tradeoffs  which 
need  to  be  considered.  This  action,  which  should  be  under 
the  advocacy  and  implementation  of  AFALD  with  close  inter¬ 
action  with  and  support  from  AFLC/LOEC  and  the  ALC's, 
should  be  fully  coordinated  with/approved  by  all  MAJCOMS 
and  interservice  agencies  involved. 


Table  A-l,  Recommendations  Which  Can  Be  Implemented  By 

Directive  or  Direct  Management  Action  (Continued) 


•  Issue:  Facility  Planning/Funding/Maintenance  (Continued) 

•  Recommendations 

As  recommended  in  Section  3.3,  take  action  to  establish  the 
CRISP  as  a  USAF-wideMOA  for  post-deployment  ECS 
resources  (viz.  support  facilities).  It  is  suggested  that  a 
request  be  submitted  to  the  JLC  to  establish  a  joint  panel  to 
assers  the  appropriateness  of  this  recommendation. 

Modify  AFR  800-14  and  other  appropriate  guidance  to  more 
clearly  identify  the  funding  responsibilities  associated  with 
post-deployment  software  support  facility  acquisition  and 
O&M. 

Develop  a  PMD/PMP/ILSP  checklist  which  can  be  used  by 
HQ  USAF,  AFLC,  AFALD,  and  field  agencies  participating 
in  ECS  acquisition  to  ensure  that  these  documents  properly 
address  support  facilities.  USAF/LOEC  should  be  encour¬ 
aged  to  non-concur  on  all  PMD's  which  do  not  adequately 
address  post-PMRT  support  facilities. 

Incorporate  facility  planning  and  funding  as  part  of  the  DSARC 
process  —  including  these  as  specific  items  in  the  "DOD 
Embedded  Computer  Resources  and  DSARC  Process 
Guidebook.  " 

In  concert  with  recommendations  tendered  in  Section  9.3, 
software  support  facilities  should  be  established  within 
AFLC  as  early  as  possible  in  the  acquisition  cycle  to  capi¬ 
talize  on  the  benefits  of  permitting  AFLC  to  carry  out  pre¬ 
deployment  activities. 

•  1 8  sue:  Funding 

•  Recommendations 

Seek  approval  for  travel  to  AFR-800  required  meetings  to 
be  funded  through  program  funds  or  given  a  high  priority 
within  BP  3400/EEIC  40X. 

Establish  definitive  funding  lines  within  AFR  800-14  and  the 
PMD's  to  route  facility  and  IV&V  funds  to  AFLC  agencies  to 
establish  support  capabilities. 
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Table  A-l.  Recommendations  Which  Can  Be  Implemented  By 

Directive  or  Direct  Management  Action  (Continued) 

•  Issue:  Funding  (Continued) 

•  Recommendations 

Insist  on  full  funding  to  accomplish  the  AFLC  assigned  mis¬ 
sion  within  the  EEIC  583  line  and  justify  this  through  an 
in-house  hardware  vs.  software  modification  cost 
comparison. 

With  full  funding  within  EEIC  583,  reduce  the  split  funding 
now  inherent  in  the  software  block  concept. 

Support  JLC  efforts  to  reduce  restrictions  to  multi-year  con¬ 
tracts  to  include  incremental  funding. 

Attempt  to  obtain  three-year  obligation  authority  for  EEIC 
583  funds. 

Develop  a  comprehensive  set  of  funding  procedures  to  include 
any  of  the  above  alternatives  in  the  form  of  an  AFLC  regula¬ 
tion  (AFLCR  800-21  now  attempts  to  do  this)  and  keep  it  cur¬ 
rent  rather  than  dissiminating  direction  through  letters,  etc. 

•  Issue:  Product/Data  Quality  at  Transition 

•  Recommendations 

Update  the  minimum  set  of  data  requirements  listed  in 
AFLCR  800-21  to  include  a  system  specification  and  software 
development/support  facility  description  documents. 

Develop  content  standards  and/or  guidance  for  documents 
not  covered  under  MIL-STD  490  and  MIL-STD  483. 

Provide  continued  AFLC  support  to  the  joint  services  effort 
aimed  at  defining  documentation  requirements  for  software 
acquisition. 

Eliminate,  through  discrimination  in  the  source  selection 
process  and  through  contractual  terms  in  the  production 
phase,  proprietary  software  which  is  either  integral  to  or 
used  in  support  of  a  USAF -maintained  ECS. 

Establish  joint  AFSC/AFLC  regulatory  guidance  that  requires 
AFLC  approval  prior  to  the  reprogramming  funds  earmarked 
for  AFLC  requirements  to  other  acquisition  areas. 


Table  A-l.  Recommendations  Which  Can  Be  Implemented  By 

Directive  or  Direct  Management  Action  (Concluded) 

•  Issue:  Product/Data  Quality  at  Transition  (Continued) 

•  Recommendations 

Continue  to  encourage  AFLC  participation  in  the  requirements 
definition  phase  of  the  acquisition  cycle  to  ensure  adequate 
resources  for  post-deployment  support  are  defined  from  the 
onset.  Measures  should  be  taken  at  AFLC  HQ  to  make  avail¬ 
able  sufficient  manpower  and  skills  to  define  and  follow-up 
these  requirements. 

•  Issue:  Management  Structure 

•  Recommendations 

Establish  a  management  division  for  each  avionics  type  or 
Federal  Supply  Class  at  the  ALC's. 

Establish  a  service  engineering  organization  with  all  digital 
hardware  and  software  engineers  at  each  ALC. 

Establish  a  software  only  organization  at  the  ALC's. 
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Table  A-2.  Recommendations  Which  Will  Require  Program 
Implementation  for  Improvement 


•  Issue:  ECS  Readiness  Support  Concept 

•  Recommendations 

Initiate  action  to  provide  a  stimulus  and  effectiveness  moni¬ 
toring  capability  for  key  avionics  systems. 

At  the  same  time,  emphasis  should  be  placed  on  documenting 
and  developing,  as  an  integral  part  of  the  stimulus /monitor¬ 
ing  equipment,  a  preemptive  engineering  and  QRC  support 
capability. 

Training  and  maintaining  within  each  support  facility  a  core 
of  expertise  in  the  areas  described  in  alternatives  above. 

•  Issue:  Personnel  and  Training 

•  Recommendations 

Develop  a  top  level  training  plan,  in  coordination  with  ATC, 
AFIT,  etc.  ,  for  ECS  O&S  engineers  and  managers.  The 
plan  developed  by  HQ  AFLC/LOEC  in  1976  represented  a 
good  start  in  this  regard.  It  is  strongly  urged  that  a  year 
to  18  month  formal  training  program  (such  as  currently 
conducted  for  flight  training,  maintenance  officer's  school, 
logistics  management  school,  etc.  )  be  developed  for  soft¬ 
ware  engineers  and  a  2-4  week  course  for  software 
managers. 

Explore  more  effective  means  of  using  the  networks  avail¬ 
able  to  AFLC  for  training  and  cross-training  devices. 

•  Issue:  Microprocessors  and  Firmware  Support 

•  Recommendations 

Develop  and  install  a  standard,  well- equipped,  growth- 
oriented  microprocessor  laboratory  at  each  of  the  five 
ALC's. 

Establish  a  joint  AFSC/AFLC/Industry  study  group  to  stan¬ 
dardize  identification  and  labeling  of  programmed  and  pro¬ 
grammable  devices. 
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Table  A-2.  Recommendations  Which  Will  Require  Program 
Implementation  for  Improvement  (Continued) 


•  Issue:  Configuration  Management 

•  Recommendations 

Detail  the  configuration  management  provided  in  AFR  800-14 
and  AFLCR  800-21  into  ALC  division  and  branch  level  pro¬ 
cedures  —  advisedly  in  the  form  of  operating  instructions 
(OIs).  Action  should  be  taken  by  HQ  AFLC/LOE  to  assure 
that  such  procedures  are  consistent  across  like  types  of 
ECS's  (i.  e.  ,  OFP,  EW,  ATD,  ATE,  CE).  These  OI's 
should  be  employed  as  items  for  AFLC  functional 
inspections . 

To  enhance  accuracy,  speed  and  cost  effectiveness,  develop 
a  common  set  of  CM  tools  (e.  g.  ,  data  management  systems, 
requirements  tracing  tools,  library  systems)  across 
ALC's  —  and,  where  applicable,  across  ECS  types. 

Conduct  a  trade-off  analysis  to  evaluate  centralized  change 
management  vs.  a  decentralized  process  (for  CE  and  ATD). 
Roles  and  missions  of  involved  agencies  should  be  carefully 
considered.  If  split  software  support  is  determined  neces¬ 
sary  for  a  special  situation,  then  support  should  be  aggre¬ 
gated  at  one  location  which  CM  performed  as  a  consolidated/ 
coordinated  effort. 

•  Issue:  Product/Data  Quality  at  T  ansition 

•  Recommendations 

Develop  an  embedded  computer  resources  guidebook  which 
can  be  used  by  source  selection  team  members.  Among 
other  AFLC  requirements  this  guidebook  should  delineate 
support  data  considerations  as  well  as  the  methodology  to 
be  used  in  developing  the  ECS  elements. 

Adopt  a  formalized  means  of  directly  and  actively  involving 
AFLC  in  the  ECS  acquisition  cycle  sufficiently  in  advance 
of  PMRT  to  ensure  a  high  quality  of  well  baselined  software 
and  related  documentation  exist  at  transfer  and  that  sufficient 
resources  (personnel,  training,  equipment,  facilities,  sup¬ 
port  software,  etc.)  are  timely  made  available  to  AFLC  to 
carry  out  life  cycle  O&S  software  support.  It  is  urged  that, 
as  part  of  this  approach,  AFLC  perform  predeployment 
IV&V  on  development  software  and  demonstrate  AFLC 
software  supportability  as  a  prerequisite  for  transfer. 

These  provisions  should  be  made  part  of  the  AFR  800-4 
PMRT  plan. 
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